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.
Related
How can one use convert or pdftk to merge several pdfs organized as a table?
For example, given 4 files: file1.pdf, file2.pdf, file3.pdf, file4.pdf, each of a single page, I would like to have a single-page pdf like
file1.pdf file2.pdf
file3.pdf file4.pdf
That is, the files are arranged like an array.
By far the easiest way to convert 4 PDF pages to 1 page on any OS is by N-Up imposition/printing with output to a virtual PDF printer such as Ghostscript. For the most basic 4-Up command line usage see https://stackoverflow.com/a/72850245/10802527
Thus to combine 4 pages (others such as 2 6 9 or 16 are possible) using here in a gui I can very easily set the order.
On Linux or MacOS you can use, along with other options, the CUPS command
lp -o number-up=4 filename
see https://www.cups.org/doc/options.html
The major advantage over using tools such as PDFtk with convert is that it resolves both scaling and preserving most PDF structures without degrading to inferior down-scaled imagery by NOT passing in and out of images before calling Ghostscript.
If you have single pdfs then you can merge before print using PDFtk (uses Ghostscript) instead of poppler pdfunite. Note that with either the Original PDF format is preserved.
If you want to convert to half size images and stitch them together, then reprint to one pdf page, then that can easily be done using imagemagik convert and other commands to call Ghostscript to suit your requirements direct. However, the results will in many ways be degraded by translation to image output.
Since all of the above pass through GS it makes sense, where possible, to install GS as a PDF printer driver.
If you want to avoid installing GhostScript printing then you can use cross platform Coherent cpdf (it only uses GS if the files need repairs)
Note these are "windows double quoted names" adjust as required and is based on the 4 sequential pages in one file are then to be placed 4 at a time on each new page, thus can be used with any multiple of pages in the input.pdf
cpdf -twoup "input.pdf" -o "in-2-Up-tmp.pdf"
cpdf "in-2-Up-tmp.pdf" -rotate 90 -o "out-2-Up.pdf"
cpdf -twoup "out-2-Up.pdf" -o "out-4-Up-tmp.pdf"
cpdf "out-4-Up-tmp.pdf" -rotate 90 -o "out-4-Up.pdf"
In linux, I use ps2pdf to convert text file report to pdf in bash script.
To feed ps2pdf for ps file, I use paps command because of UTF8 encoding.
The problem is pdf file from ps2pdf is about 30 times bigger than ps file created from paps.
Previous, I used a2ps to convert text to ps and then fed to ps2pdf, and the pdf output from this is normal size and not big.
Is there any way to reduce the pdf size from paps and ps2pdf? Or what am I doing wrong?
The command I used is as below.
paps --landscape --font="Freemono 10" textfile.txt > textfile.ps
ps2pdf textfile.ps textfile.pdf
Thank you very much.
As the author of paps, I agree with #Kens's description of paps' inner workings. Indeed, I chose to create my own font mechanism in the postscript language. That is history though as I have just released a new version of paps that uses cairo for its postscript, pdf, or svg rendering. This is much more compact than paps output, especially w.r.t. the result after doing ps2pdf. Please check out http://github.com/dov/paps .
For ps2pdf, it is easiest to control output size is by designating paper size.
An example command is:
ps2pdf -sPAPERSIZE=a4 -dOptimize=true -dEmbedAllFonts=true YourPSFile.ps
ps2pdf is the wrapper to ghostscript (ps2pdf is owned by ghostscript package)
with -sPAPERSIZE=something you define the paper size. Wondering about valid PAPERSIZE values? See [http://ghostscript.com/doc/current/Use.htm#Known_paper_sizes here]
-dOptimize=true let's the created PDF be optimised for loading
-dEmbedAllFonts=true makes the fonts look always nice
All of this is from : https://wiki.archlinux.org/index.php/Ps2pdf
I think he means the size on disk, rather than the size of the output media. The 'most likely' scenario normally is that the source contains a large DCT encoded image (JPEG) which is decoded and then compressed losslessly into the PDF file using something like flate.
But that can't be the case here, as its apparently only text. So the next most likely problem is that the text is being rasterised, which suggests some odd fonts in the PostScript, which is possible if you are using UTF-8 text, its probably constructing something daft like a CIDFont with TrueType descendant fonts.
However, since the version of Ghostscript isn't given, and we don't have a file to look at, its really impossible to tell. Older versions of the pdfwrite device did less well on creating optimal files, especially from CIDFonts.
Setting 'Optimize=true' won't actually do anything with the current version of pdfwrite, that's an Acrobat Distiller parameter we no longer implement. Older versions of Ghostscript did use it, but the output wasn't correctly Linearised.
The correct parameter for newer versions is '-dFastWebView' which is supposed to be faster when loading from the web if the client can deal with this format. Given the crazy way its specified, practically no viewer in the world does. However, the file is properly constructed in recent versions, so if you can find a viewer which supports it, you can use this (at the expense of making the PDF file slightly larger)
If you would like to post a URL to a PostScript file exhibiting problems I can look at it, but without it there's really nothing much I can say.
Update
The problem is the paps file, it doesn't actually contain any text at all, in a PostScript sense.
Each character is stored as a procedure, where a path is drawn and then filled. This is NOT stored in a font, just in a dictionary. All the content on the page is stored in strings in a paps 'language'. In the case of text this simply calls the procedure for the relevant glyph(s)
Now, because this isn't a font, the repeated procedures are simply seen by pdfwrite (and pretty much all other PostScript consumers) as a series of paths and fills, and that's exactly what gets written to the output in the PDF file.
Now normally a PDF file would contain text that looks like :
/Helvetica 20 Tf
(AAA) Tj
which is pretty compact, the font would contain the program to draw the 'A' so we only include it once.
The output from paps for the same text would look like (highly truncated) :
418.98 7993.7 m
418.98 7981.84 l
415.406 7984.14 411.82 7985.88 408.219 7987.04 c
...
... 26 lines omitted
...
410.988 7996.3 414.887 7995.19 418.98 7993.7 c
f
418.98 7993.7 m
418.98 7981.84 l
415.406 7984.14 411.82 7985.88 408.219 7987.04 c
...
... 26 lines omitted
...
410.988 7996.3 414.887 7995.19 418.98 7993.7 c
f
418.98 7993.7 m
418.98 7981.84 l
415.406 7984.14 411.82 7985.88 408.219 7987.04 c
...
... 26 lines omitted
...
410.988 7996.3 414.887 7995.19 418.98 7993.7 c
f
which as you can clearly see is much larger. Whereas with a font we would only include the instructions to draw the glyph once, and then use only a few bytes to draw each occurrence, with the paps output we include the drawing instructions for the glyph each and every time it is drawn.
So the problem is the way paps emits PostScript, and there is nothing that pdfwrite can do about it.
That said, I see that you are using Ghostscript 8.71 which is now 4 years old, you should probably consider upgrading.
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.
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.
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