Customer reports: While experimenting with BufferSpace, I've found something else. GS 8.53 fails to rip the attached file at 2800 dpi and higher, with a bufferspace of 2 Mb: gs -DBufferSpace=2000000 -sDEVICE=tiff32nc -sOutputFile=a.tif -r28000 -dNOPAUSE -f trans.pdf -c quit Error: /rangecheck in --.fillpage-- etc... I've tracked the problem a little bit, and found the cause of the problem: clist_init_states() returns gs_error_range_check because the "data_size" is too small. As a result, the device has "permanent_error" set to -15 and clist_fill_rectangle immediately fails. I don't understand exactly what happens. clist_init_states() is called 2 times with this file (I suppose it's because of the transparency), and the second times the number of bands is much higher than the first time. Thus the data_size is too small. I see in gdev_prn_setup_as_command_list that the BufferSpace value is used as base value to compute the data_size. Thus with a higher BufferSpace (e.g. 5 Mb) you need to augment the resolution to reproduce the problem. Currently we never use less than 10 Mb with our devices. I've computed that, roughly, we need 2m x 2m at 1500 dpi to cause the problem. Not very common, but possible in a near future. Some printers (5m width) will soon reach 800 dpi, so we are not so far.
Created attachment 2387 [details] trans.pdf
Since I have the other BufferSpace bug, I'll take this one too.
Customer bugs should be P2.
The tiff32nc device can only support up to 2Gb raster images (since it is uncompressed). For this file 'trans.pdf' (a 'letter' size page) the maximum resolution that will fit is -r2310 or thereabouts. Note that the current ghostscript fails with: Error: /rangecheck in --showpage-- when the page is too large for uncomressed tiff. Otherwise, the issues with transparency and large pages have all been fixed.