Bug 693016 - ps2write generates large file that take a long time to print
Summary: ps2write generates large file that take a long time to print
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Writer (show other bugs)
Version: master
Hardware: PC All
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-01 14:08 UTC by Marcos H. Woehrmann
Modified: 2014-02-17 04:43 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Ausgabe1-evince.pdf (1.77 MB, application/pdf)
2012-05-01 14:09 UTC, Marcos H. Woehrmann
Details
Ausgabe1-evince.ps.gz (10.06 MB, application/x-gzip)
2012-05-01 14:11 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2012-05-01 14:08:55 UTC
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
Comment 1 Marcos H. Woehrmann 2012-05-01 14:09:37 UTC
Created attachment 8557 [details]
Ausgabe1-evince.pdf
Comment 2 Marcos H. Woehrmann 2012-05-01 14:11:52 UTC
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).
Comment 3 Ken Sharp 2012-05-01 15:01:11 UTC
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.
Comment 4 James Cloos 2012-05-01 16:41:45 UTC
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....
Comment 5 Ken Sharp 2012-05-01 20:49:27 UTC
(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.
Comment 6 Ken Sharp 2012-05-01 21:08:07 UTC
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.
Comment 7 James Cloos 2012-05-02 00:00:30 UTC
<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>