[cups.general] Sense and nonsense of RIPCache

Till Kamppeter till.kamppeter at gmail.com
Tue Jul 27 03:41:08 PDT 2010


Hi,

I am running into a problem with Ghostscript used in pstoraster and 
pdftoraster. See

http://bugs.ghostscript.com/show_bug.cgi?id=691499

There I have found out that very complex input files printed at high 
resolutions or with big paper sizes one needs to set the RIPCache in 
cupsd.conf to a high value.

All other drivers based on Ghostscript rendering (built-in drivers like 
"ljet4", drivers using another raster format like "pnm2ppa", ...) do not 
raise such complaints.

One could now simply say one should raise the default from the 
ridiculous 8 MB and I also did thid by patching the CUPS which comes 
with Ubuntu (there I use 1/4 of the actual RAM).

But if other Ghostscript drivers do the right thing automatically, why 
do we not let the CUPS Raster driver in Ghostscript also use 
Ghostscript's automatic memory management and drop the 
cups_get_space_params() function which sets the memory buffers used by 
Ghostscript to values based on RIPCache?

I have commented out this function to let Ghostscript on its own 
concerning buffer sizes and it perfectly rendered the file attached to 
the bug mentioned above at 7200x7200 dpi. And memory consumption of 
Ghostscript stayed under 256 MB on my 4G RAM machine. It even happily 
renders this job with 72000x72000 dpi and stays under 1 GB of memory 
consumption. So with the support for RIPCache dropped Ghostscript would 
just work with Gutenprint using 5760x2880 dpi on an A0 6-ink Epson 
Stylus Pro printer.

What is the RIPCache important for? Why do we default it to 8MB? Why 
don't we let Ghostscript and imagetoraster determine the available 
memory automatically? Or should we better default to automatic setting 
by the filters if the RIPCache in cupsd.conf is not set (simply let CUPS 
not set the environment variable RIP_MAX_CACHE if RIPCache is not set)?

WDYT?

    Till





More information about the cups mailing list