Comment 10 for bug 1815339

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

Created attachment 16878
appout.pdf

The problem is that with a certain PDF file (appout.pdf, attached) and certain parameters Ghostscript 9.26 fails when specifying a high value of the RIP_MAX_CACHE environment variable but succeeds when specifying a lower value or no RIP_MAX_CACHE at all. The problem does not occur with Ghostscript 9.22 though.

Here is a reproducer command line:

cat appout.pdf | RIP_MAX_CACHE=128m gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout='%stderr' -sOutputFile='%stdout' -sDEVICE=cups -sMediaClass=Cassette -sMediaType=Plain -r600x600 -dDEVICEWIDTHPOINTS=288 -dDEVICEHEIGHTPOINTS=432 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=6 -dcupsRowFeed=2 -scupsPageSizeName=w288h432 -I/usr/share/cups/fonts -c '<</.HWMargins[0.000000 0.000000 0.000000 0.000000] /Margins[0 0]>>setpagedevice' -f -_ > out.raster

Whether it fails or not depends on the numeric value of the RIP_MAX_CACHE environment variable. For me all values up to 32.986m succeed and 32.987m and higher fails. Not supplying the RIP_MAX_CACHE also succeeds which is the reason whether the first attempts to run Ghostscript on the command line have succeeded.

Strange is that low values of RIP_MAX_CACHE succeed and high values fail, so it does not seem to be a problem of too small memory.

cups/gdevcups.c reads RIP_MAX_CACHE in the cups_get_space_params() function and drops the specified memory size in a gdev_prn_space_params data structure, in both MaxBitMap and BufferSpace fields. And it does this only if the RIP_MAX_CACHE variable exists and has a valid value (non-zero float number with unit k, m, or g). AFAIK it is only used in the "cups" output device, so in all other devices Ghostscript seems to handle MaxBitMap and BufferSpace by itself.

Question is here not only what is going wrong but also whether Ghostscript is perhaps better in setting these sizes by itself and so should we perhaps drop the RIP_MAX_CACHE variable altogether (remove the support for it in cups/gdevcups.c?, set its default in CUPS to the invalid value 0?)?