Till reports that the attached file generates a large PostScript file that takes a long time to print. The command line I'm using testing: bin/gs -sDEVICE=ps2write -o test.ps ./Ausgabe1-evince.pdf
Created attachment 8557 [details] Ausgabe1-evince.pdf
Created attachment 8558 [details] Ausgabe1-evince.ps.gz This is the example file converted from PDF to PS by poppler that is smaller than the PS file generated by Ghostscript and prints much faster (I have not verified how much faster).
The Poppler output is broadly similar to our own. The PDF file contains a number of pages which contain transparency (The coloured highlighted equations for example). Because the PDF file was produced by Cairo, the transparency is contained within groups which are all declared as covering the entire page. Because the PostScript graphics model does not include transparency, this means that the entire page must be rendered to an image and the image included in the output. Both the Poppler output and the Ghostscript output do this for these pages. So why the difference in size ? Because the Poppler images are rendered at 300 dpi whlie the Ghostscript output is rendered at the default ps2write resolution of 720 dpi. As a reult I would expect those pages to be (approximately) 5 times larger. Larger images *may* require the printer to downsample the image data, which can be slow on a printer, and of course it takeds more time to transmit the data. You can alter the resolution that ps2write uses with the -r switch. If I run this file at (for example) 150 dpi, the resulting PostScript file is 15Mb, considerably smaller than the poppler output (70Mb). 200 dpi comes in at 25Mb and 300 dpi is a 50Mb file. I'm not in a position tom compare the performance of the files, since that will depend heavily on the actual printer being used.
I gave the pdf a test. With -r600 I get: 65493542 May 1 11:27 att_8557.pdftops3 70270497 May 1 11:27 att_8557.pdftops2 185028158 May 1 11:36 att_8557.pdf2ps (Cups’ pdftops filter will pass -level3 to pdftops if the queue’s ppd specifies that the printer supports level3, so I included that, too.) Stat(1) shows that pdftops took about 2 minutes and pdf2ps took 10½ minutes. This also is interesting: :; time gs -dBATCH -dNOPAUSE att_8557.pdftops3 GPL Ghostscript 9.05 (2012-02-08) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. real 0m9.448s user 0m7.636s sys 0m0.380s :; time gs -dBATCH -dNOPAUSE att_8557.pdftops2 GPL Ghostscript 9.05 (2012-02-08) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. real 0m9.427s user 0m7.924s sys 0m0.390s :; time gs -dBATCH -dNOPAUSE att_8557.pdf2ps GPL Ghostscript 9.05 (2012-02-08) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. real 0m30.247s user 0m27.553s sys 0m0.516s so even gs renders ps2writer output slower than it does pdftops output. (A build of pspcl6 from last weekend’s master took about 13s to render the pdftops output and about 69 seconds to render the pdf2ps ouput.) Of course, newer versions of cairo do a better (less naïve) job determining the extent of transparency regions that 1.10 did. And part of the bug is Evince’s unfortunate insistance on recreating documents for print rather than passing the originals on to the print system....
(In reply to comment #4) > I gave the pdf a test. With -r600 I get: > > 65493542 May 1 11:27 att_8557.pdftops3 > 70270497 May 1 11:27 att_8557.pdftops2 > 185028158 May 1 11:36 att_8557.pdf2ps The size you quote is approximately what I wouuld expect from a resolution of 600 dpi, but please note that the resolution (of the file we were supplied as an example) of the Poppler output is 300 dpi, not 600. I did mention this in comment #3 > Stat(1) shows that pdftops took about 2 minutes and pdf2ps took 10½ minutes. Rendering at a higher resolution will, of course, take more time. There is 4 times the amount of data, so this is broadly what I would expect. > so even gs renders ps2writer output slower than it does pdftops output. Again this is not surprising. At the very least there is 2-3 times as much data to read off disk.
I just did a very quick comparison of the 300 dpi ps2write output and the 300 dpi Poppler output. Using Ghostscript the ps2write output took 25 seconds and the Poppler output took 26 seconds. I only did a single run so this is not reliable data, but I consider these to be identical for practical purposes. I believe that if the ps2write resolution is the same as the Poppler rendered resolution, then the time should be approximately the same. I can't test the conversion time to postScript as I'm currently at a meeting and only have access to a Windows laptop.
<brown_paper_bag_mode> My intent was the render all three at -r600, but it seems that I failed to do that. Fixing that shows that the three are indeed similar size. </brown_paper_bag_mode>