Summary: | Very slow scaling of transparent data | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | iam |
Component: | PDF Interpreter | Assignee: | Default assignee <ghostpdl-bugs> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 10.02.1 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: | 4 page test PDF file with transparency |
Description
iam
2024-01-31 13:34:25 UTC
Created attachment 25292 [details]
4 page test PDF file with transparency
Tested on ghostscript 10.0.0~dfsg-11+deb12u3 @ debian 12, ghostscript ghostscript-10.02.1-2.fc39.x86_64 @ fedora 39.
price.pdf is a sample 4-page file
price_fedora.pdf is a processed file in the following way:
/usr/lib/cups/filter/pdftopdf 0 0 0 0 0 price.pdf > price_fedora.pdf
$ time /usr/bin/gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=%stderr -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=%stdout -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE -dNOTRANSPARENT /tmp/price.pdf > /dev/null real 0m10.981s user 0m10.360s sys 0m0.570s $ time /usr/bin/gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=%stderr -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=%stdout -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE -dNOTRANSPARENT /tmp/price_fedora.pdf > /dev/null real 0m39.461s user 0m37.750s sys 0m1.510s # Now with -dNOTRANSPARENCY $ time /usr/bin/gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=%stderr -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=%stdout -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE -dNOTRANSPARENCY /tmp/price.pdf > /dev/null real 0m4.719s user 0m4.440s sys 0m0.200s $ time /usr/bin/gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=%stderr -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=%stdout -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE -dNOTRANSPARENCY /tmp/price_fedora.pdf > /dev/null real 0m4.614s user 0m4.380s sys 0m0.200s (In reply to iam from comment #0) > When the PDF file is processed with CUPS pdftopdf program (which adds > different scaling and cropping options inside the PDF file as far as I > understand), ghostscript is very slow to convert it into PS. PostScript does not have an equivalent transparency model to PDF, so the **only** way to turn a transparent PDF into PostScript, and have the result be correct, is to render it to an image and wrap the image up as PostScript. >This file apparently contains transparent operations, as running it with ->dNOTRANSPARENCY speeds up processing by 10+ times. And produces incorrect output. > That's why I assume that GhostScript PDF interpreter's scaling operations > with transparency involved is very slow. Your assumption is incorrect. The ps2write device (NOT Ghostscript, the PostScript output device) is rendering the output. Rendering takes significantly more time, at higher resolutions, than simply processing high level objects. As far as I can see only the final page actually uses transparency. We cannot turn transparency on and off per page, only per document. That's a limitation of the graphics library. You could, if you wish, try splitting the file up and processing each page separately. (In reply to Ken Sharp from comment #4) > >This file apparently contains transparent operations, as running it with ->dNOTRANSPARENCY speeds up processing by 10+ times. > > And produces incorrect output. Yes, unfortunately. > Rendering takes > significantly more time, at higher resolutions, than simply processing high > level objects. I see, thanks. > > As far as I can see only the final page actually uses transparency. We > cannot turn transparency on and off per page, only per document. That's a > limitation of the graphics library. > > You could, if you wish, try splitting the file up and processing each page > separately. Well, this is a printing pipeline where transparent PDFs are quite common (even if they don't contain any real transparency) and any manual intervention is undesirable. I don't *need* postscript really, it's just a pipeline for many (older) printer drivers, many of which convert to entirely different format afterwards themselves. For now I'm using Poppler wherever possible, but many drivers call ghostscript filters by themselves, which may significantly slow down the printing process depending on the file unfortunately. |