[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