I have a Pandoc .md document which contains a standard, 3-line title block as follows:
% title
% author
% date
Pandoc converts this document via LaTeX to a PDF:
pandoc --variable papersize:"a4paper" -s -S -o output.pdf document.md
The title block displays as I expect, but I'd like to move it so that it occupies a predefined space -- a centered 100mm x 60mm rectangle starting at 70mm down the page.
I'd be happy to use trial and error rather than exact measurements when trying to place the title block, but at the moment I cant even find a way to move it all.
This did not seem to be possible.
In the end I used a word processor to print out the title page and used Pandoc for the rest.
I'm still open to suggestions, but giving this answer the tick for now.
Related
I have one question regarding the pdf structure, why % sign is used in pdf.
I got some results where they mentioned % sign is used for comments but if we use % sign for comments then what about % sign used in %PDF-1.5 and %%EOF?
%PDF-1.5 which defines the header of the file and
%%EOF which defines the end of the pdf structure.
then why is the % sign used for PDF-1.5 and why is the % sign used 2 times in EOF?
From the results I knew that % sign is used for comments, so why it is different for above two terms?
Your help will be appreciated - Thank you
I actually know nothing about pdf structure or using % correctly, but it seems to have the same reasons as the shebang #! followed by an executable is required in shell scripts, like bash, perl, or even python.
More can be read at this stack overflow answer here for why bash scripts need the #! at the beginning of scripts: https://stackoverflow.com/a/8968514/6037755
why is the % sign used for PDF-1.5 and why is the % sign used 2 times in EOF?
From the results I knew that % sign is used for comments, so why it is different for above two terms?
You can consider those entries actually to be comments (after all they do not contain any PDF objects as such to use for PDF rendering) which you are required to put at certain positions of a PDF file.
According to the specification ISO 32000-1:
7.5.2 File Header
The first line of a PDF file shall be a header consisting of the 5 characters %PDF– followed by a version number of the form 1.N, where N is a digit between 0 and 7.
and
7.5.5 File Trailer
The trailer of a PDF file enables a conforming reader to quickly find the cross-reference table and certain special objects. Conforming readers should read a PDF file from its end. The last line of the file shall contain only the end-of-file marker, %%EOF.
As the use of "shall" here indicates, these are requirements.
And it indeed makes sense that these markers in all other respects are comments.
Only for the purpose of identifying the start and the end of a PDF these markers have a special meaning, before a PDF processor starts working with actual PDF objects. As soon as start and end are identified, these markers have to be ignored. So, making these markers comments is an obvious choice.
This is true for unusual processing types, too. E.g. if for some reason the cross references of a PDF are broken and some program tries to re-create them by searching for indirect PDF objects, it does not need to specially treat these markers, it automatically ignores them as comments.
PS According to Adobe's Implementation Notes in the Annex H of their PDF Reference, their tools also accept an alternative header:
3.4.1, “File Header”
[...]
14.Acrobat viewers also accept a header of the form
%!PS−Adobe−N.n PDF−M.m
If you want to find out why the marker comment contents were chosen exactly like they they are, therefore, you should look into the history of PDF and Postscript
I'm using the Domestic shipping label api in usps to generate domestic shipping labels in pdf format. I managed to crop the top section of the pdf file which is the label needed by the usps and Ignored the bottom section which is the receipt which is not needed in shipping.
I use Ghostscript /Cropbox to crop the section that I only want which is successful but when I try to print the cropped pdf file in linux cups I get the whole uncropped pdf printed instead of the cropped pdf file. Why is it still printing the whole file instead of just printing the cropped section?.
Here's the script I'm using to crop the usps Shipping label.
gs -o cropped.pdf -sDEVICE=pdfwrite -c "[/CropBox [50.4 460.5 484.4 750.5] /PAGES pdfmark" -f uncropped.pdf
Then to change its orientation to portrait i use pdftk
pdftk cropped.pdf cat 1L output cropped_portrait.pdf
To print it in linux cups I'm using the command.
lp cropped_portrait.pdf
But when i print it it is printing the uncropped.pdf file instead of cropped_portrait.pdf.
Why is it doing that? I even deleted uncropped.pdf and tried printing again but it still prints uncropped.pdf.
Here's the two files the uncropped and cropped usps shipping labels.
Uncropped PDF file
Cropped PDF file
Hope you can help me on this one,
Thank you
Presumably the reduced PDF file displays correctly, so there is no problem with Ghostscript producing the PDF file.
As to why the printing process doesn't respect the CropBox, there is no reason really why it should. There are many Boxes in PDF and no real way for a print application to know which one you want to use. As a result printing applications often default to the MediaBox, which you haven't altered (Note that altering the CropBox doesn't change the content of the PDF file, just what is displayed).
Now, if your CUPS chain is using Ghostscript to render the PDF file, or convert it to PostScript, then this can be solved, you need to add -dUseCropBox to the command line. However I'm not a CUPS expert so I can't tell you how to do that. If CUPS isn't using Ghostscript then its probably still possible to instruct whatever is doing the conversion to use the CropBox, but you're going to have to find out what application is involved and alter the command appropriately for that application.
I have a large collection of half-page sized PDF cut-sheets that are held in a folder on my Linux server. A user to the site will want to create a booklet from a subset of these. The booklet will be bound therefore the even pages of the collection will want more margin on the right side and the odd pages will want more margin on the left side. There can be up to 200 pages in a collection out of a universe of 500 pages so I don't want to regenerate each page to set the margin of it. It would take too much of the servers time to run the content through the DOMPDF. Just building the document using PDFTK is fast.
I'd like to merge the document with PDFTK from a centered PDF file and add the appropriate margin for the odd or even page.
If not PDFTK then is there another tool that might do the job?
If you use ubuntu, you can install pdfcrop:
sudo apt-get install -y pdfcrop
Despite its name, pdfcrop has the option to add margins:
pdfcrop --margin '29 0 29 0' input.pdf output.pdf
(Note: the unit is bp. 72 bp = 1 inch. 29 bp is approximately 1 cm.)
Then, use pdfjam to do the offset trick for the right and left pages.
pdfjam --twoside --offset '1cm 0cm' file.pdf
Note: pdfcrop does have problems with some pdf files. (!!! Error: Ghostscript exited with error code 139!).
If you are still interested in this, you should have a look at pdfjam which allows you to offset and clip pdfs. With respect to your particular question you might do something like
pdfjam --twoside --offset '2cm 0cm' file.pdf
This shifts the even pages 2cm to the right and the odd one to the left.
pdfjam is a front end to the pdfpages package of pdflatex.
Even if it is a bit late, but it might help someone. In response to #ElkeSpaak comment, it's the package texlive-extra-utils:
dpkg-query -S /usr/bin/pdfcrop
texlive-extra-utils: /usr/bin/pdfcrop
We want to print big drawings (up to A0 and some times longer) to A3 printers using ghostscript:
gs -o - -sDEVICE=pdfwrite -r1200x1200 -sPAPERSIZE=a3 -f
/S/tmp/SamplePDFnewStamp.pdf | gs -o resized.pcl -sDEVICE=ljet4
-g7012x4961 -dPDFFitPage -
I get A4 landscape on an A3 portrait Paper. I also tried to rotate:
gs -sOutputFile="-" -sDEVICE=pdfwrite -r1200x1200 -sPAPERSIZE=a3 -d
-dBATCH -dNOPAUSE -dAutoRotatePages=/None -dPDFFitPage -c "<</Orientation 1>> setpagedevice 90 rotate 0 -595 translate" -f
/S/tmp/SamplePDFnewStamp.pdf -c quit | gs -o resized.pcl
-sDEVICE=ljet4 -g7012x4961 -dPDFFitPage -
getting the same result.
Its not really possible to comment without seeing a PDF file, but a number of the command line options you are using there don't make sense in the combination you have.
The first thing I would do is stop piping the commands like that, at least while investigating the problem. Do it as 2 stages, that will allow you (and others) to look at the intermediate PDF file.
Secondly, I don't believe you can do what you seem to be trying to do. It looks like you are trying to pipe the PDF produced by the first invocation of gs through the second invocation. I don't see any way that will work, the pdfwrite device needs to seek around the file in order to create the xref table, it cannot use stdout, at least in the current version. What version of Ghostscript are you using ?
I also can't see the point of this, why take a PDF, make a new PDF from it, and then render the second PDF ? Why not just render the original ?
None of the media size switches you are specifying will have any effect, because you haven't told Ghostscript that the media size is fixed (using -dFIXEDMEDIA). As a result the PDF interpreter will set the media size to be the same as the MediaBox in the PDF file. Similar problems apply with sending PostScript and expecting it to alter the behaviour of Ghostscript when rendering a PDF file.
Setting the resolution for pdfwrite is not a good idea, and will in general have no effect. Even if it does have an effect, you probably don't want to set it to be the resolution of the device (and the -g values seem to suggest this is not a 1200 dpi device either). The only effect the resolution has is when objects have to be rendered to images because the can't be represented in PDF. You don't want to create images at the printer resolution, somewhere between one quarter and one half the resolution is usually sufficient.
If you'd care to share an example PDF file, I may be able to tell you how to solve your orientation problem. You will need to explain why you are running it through pdfwrite before going to PCL though, I can't see any reason for that.
This:
gs -sDEVICE=pdfwrite -sOutputFile=\temp\out.pdf -dDEVICEHEIGHTPOINTS=2386.08 -dDEVICEWIDTHPOINTS=1685.7600 -dFIXEDMEDIA -dPDFFitPage SamplePDFnewStamp.pdf
Will take your original PDF file and produce a PDF file rotated by 90 degrees. If I then do:
gs -sDEVICE=ljet4 -sOutputFile=\temp\out.pcl \temp\out.pdf
I get a PCL file that, when processed by GhostPDL with appropriate media size, seems to do what you want.
I haven't tried it, due to lack of an actual device to print on, but I would expect that:
gs -sDEVICE=ljet4 -sOutputFile=\temp\out.pcl -dDEVICEHEIGHTPOINTS=2386.08 -dDEVICEWIDTHPOINTS=1685.7600 -dFIXEDMEDIA -dPDFFitPage SamplePDFnewStamp.pdf
would produce the same file in one step.
I found a solution:
gs -q -sDEVICE=ljet4 -sOutputFile=out.pcl -dFIXEDMEDIA -dPDFFitPage -sPAPERSIZE=a3 \-c "<</Install {-1 -1 scale -843 -1192 translate}>> setpagedevice" -f SamplePDFnewStamp.pdf -c quit
I'm written a program on a legacy app (Progress 4GL on SCO Unix 5.0.7 - - I know, I know) to generate a postscript file line by line. If I open the .ps file in PDFCreator, it renders everything just like I want.
But, I need to get it into pdf format. When I use ps2pdf to do that by:
ps2pdf mypsfile.ps newpdffile.pdf
and open the pdf in PDFCreator or Acrobat, I get a single blank page (expected output is one page).
If I chop the .ps file down to something that yields a simple one line output, I still get a blank .pdf page. This .ps also renders fine in PDFCreator:
/Arial findfont
12 scalefont
setfont
175 700 moveto
(ABC Company) show
showpage
ps2pdf isn't displaying any errors. Can someone tell me what I need to add to the .ps code above to have it correctly convert to a PDF?
This PDF becomes overlay text on 'top of' another PDF using pdftk. When I have two "good" PDF's, that part works fine as well. It's just the converting ps to pdf that I'm stuck on.
Thanks,
David
That ought to work fine. First question is 'which version of Ghostscript are you using ?' Have you tried using Ghostscript directly instead of using the ps2pdf script ? Something like
gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=<output.pdf> <input.ps>
You haven't set a media size request, so its possible that GS is defaulting to Letter, and your text is simply off the top of the page. Try placing the text at 0,0 instead of 175, 700.