Ghostscript processing of pdf is much slower after pdftopdf

[ValdikSS]

Describe the bug

Conversion of PDF to PostScript is much slower with pdftopdf-processed file compared to the original file: 1.2 seconds vs 10 seconds on a low end Cortex-A7 device.

Default CUPS test page, original:

# time /usr/bin/gs -dNumRenderingThreads=2 -dMaxBitmap=100m -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=%stderr -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=%stdout -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE /usr/share/cups/data/default-testpage.pdf > /dev/null

real    0m1.275s
user    0m1.200s
sys     0m0.060s

Default CUPS test page, processed:

# time PPD=/etc/cups/ppd/MF3010.ppd /usr/lib/cups/filter/pdftopdf 0 0 0 0 0 < /usr/share/cups/data/default-testpage.pdf  > /tmp/page_manual
DEBUG: pdftopdf: No FINAL_CONTENT_TYPE environment variable, could not determine whether to log pages or not, so turned off page logging.
DEBUG: pdftopdf: Last filter determined by the PPD: None; FINAL_CONTENT_TYPE: (null) => pdftopdf will not log pages in page_log.
DEBUG: PDF interactive form and annotation flattening done via QPDF
DEBUG: pdftopdf: "print-scaling" IPP attribute: auto
DEBUG: pdftopdf: Print scaling mode: Do not scale, center, crop if needed
After Cropping: 595.275574 841.889771 595.299988 841.900024

real    0m0.350s
user    0m0.240s
sys     0m0.030s

root@uowprint:~# time /usr/bin/gs -dNumRenderingThreads=2 -dMaxBitmap=100m -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=%stderr -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=%stdout -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE /tmp/page_manual > /dev/null

real    0m10.415s
user    0m9.960s
sys     0m0.410s

To Reproduce Steps to reproduce the behavior:

1. Repeat the commands above to compare processing speed

Expected behavior No significant processing speed changes

System Information:

• OS: Debian 12
• Version: Ghostscript 10.0.0~dfsg-11+deb12u3, cups 2.4.2-3+deb12u5, cups-filters 1.28.17-3

[ValdikSS]

Files: Archive.tar.gz

[ValdikSS]

On a desktop machine, with 4-page PDF file, on Fedora 39: 1s vs 4.2s. price.pdf

$ time gs -dNumRenderingThreads=1 -dMaxBitmap=100m -q -dNOPAUSE -dBATCH -dSAFER -sstdout=%stderr -sDEVICE=ps2write -sOUTPUTFILE=%stdout -r600 price.pdf > /dev/null

real    0m0,966s
user    0m0,926s
sys     0m0,037s

$ /usr/lib/cups/filter/pdftopdf 0 0 0 0 0 price.pdf > price_fedora.pdf
WARN: Could not determine the output page dimensions, falling back to US Letter format
WARN: cfFilterPDFToPDF: Could not determine the width of the left margin, falling back to 18 pt/6.35 mm
WARN: cfFilterPDFToPDF: Could not determine the width of the bottom margin, falling back to 36 pt/12.7 mm
WARN: cfFilterPDFToPDF: Could not determine the width of the right margin, falling back to 18 pt/6.35 mm
WARN: cfFilterPDFToPDF: Could not determine the width of the top margin, falling back to 36 pt/12.7 mm
DEBUG: cfFilterPDFToPDF: Determined whether to log pages or not using output data type.
DEBUG: final_content_type = NULL => page_logging = -1
DEBUG: cfFilterPDFToPDF: Processing PDF input with QPDF: Page-ranges, page-set, number-up, booklet, size adjustment, ...
DEBUG: cfFilterPDFToPDF: "print-scaling" IPP attribute: none
DEBUG: cfFilterPDFToPDF: Print scaling mode: Do not scale, center, crop if needed

$ time gs -dNumRenderingThreads=1 -dMaxBitmap=100m -q -dNOPAUSE -dBATCH -dSAFER -sstdout=%stderr -sDEVICE=ps2write -sOUTPUTFILE=%stdout -r600 price_fedora.pdf > /dev/null

real    0m4,271s
user    0m4,182s
sys     0m0,080s

[ValdikSS]

Adding -dNOTRANSPARENCY speeds it up significantly.

 time gs -dNumRenderingThreads=1 -dMaxBitmap=100m -q -dNOPAUSE -dBATCH -dSAFER -sstdout=%stderr -sDEVICE=ps2write -sOUTPUTFILE=%stdout -r600 -dNOTRANSPARENCY price_fedora.pdf > /dev/null

real    0m0,162s
user    0m0,134s
sys     0m0,027s

[tillkamppeter]

-dNOTRANSPARENCY can lead to some PDF files not getting correctly printed, see the Ghostscript documentation:

-dNOTRANSPARENCY
    Turns off PDF 1.4 transparency, resulting in faster (but possibly incorrect) rendering
    of pages containing PDF 1.4 transparency and blending.

[ValdikSS]

Yes, I know, I have PDF files which are incorrectly printed with -dNOTRANSPARENCY, so this is not an option for regular printing. Is this a known issue with ghostscript? I suppose it's very slow on scaling with transparency support enabled.

[tillkamppeter]

Can you add -dInterpolateControl=0 to your Ghostscript command line? Does this help (please do not forget to remove -dNOTRANSPARENCY)?

[ValdikSS]

Can you add -dInterpolateControl=0 to your Ghostscript command line? Does this help (please do not forget to remove -dNOTRANSPARENCY)?

No changes.

$ time gs -dNumRenderingThreads=1 -dMaxBitmap=100m -q -dNOPAUSE -dBATCH -dSAFER -sstdout=%stderr -sDEVICE=ps2write -sOUTPUTFILE=%stdout -r600 price_fedora.pdf > /dev/null

real    0m4,252s
user    0m4,160s
sys     0m0,085s

$ time gs -dNumRenderingThreads=1 -dMaxBitmap=100m -q -dNOPAUSE -dBATCH -dSAFER -sstdout=%stderr -sDEVICE=ps2write -sOUTPUTFILE=%stdout -r600 -dInterpolateControl=0 price_fedora.pdf > /dev/null

real    0m4,189s
user    0m4,105s
sys     0m0,076s

[ValdikSS]

https://bugs.ghostscript.com/show_bug.cgi?id=707523

[ValdikSS]

So apparently debian's CUPS default-testpage.pdf contains transparency, and Ghostscript converts everything (at least the data require processing) in the whole document to raster data when converting PDF with transparency to PostScript, even if only a single page of the document has transparency.