Bug 691499

Summary: CUPS Raster device has "Error: /undefined in --setpagedevice--" for some files only in banding mode
Product: Ghostscript Reporter: Till Kamppeter <till.kamppeter>
Component: CUPS driverAssignee: Till Kamppeter <till.kamppeter>
Status: RESOLVED FIXED QA Contact: Bug traffic <tech>
Severity: normal    
Priority: P4 CC: alex, ken.sharp, mike, ray.johnston, regisr, twaugh
Version: master   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: Offending file: CityMap.pdf
log file of rendering CityMap.pdf
Offending file: LGMv7a_low.pdf
log file of rendering LGMv7a_low.pdf
Offending file: SMP_Warwick_14.pdf
log file of rendering SMP_Warwick_14.pdf

Description Till Kamppeter 2010-07-26 14:25:05 UTC
I am trying to render the attached PDF files with a command line like this:

cat ~/ghostscript/gpl/testfiles/cups-does-not-show/CityMap.pdf | gs -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -r720x720 -dcupsBitsPerColor=8 -dcupsColorSpace=1 -_ > out.raster 2> log

This makes Ghostscript (both 8.71 and 9.00 of current SVN) error out like this:

Error: /undefined in --setpagedevice--
Operand stack:
   (/tmp/gs_OZCmcT)   --nostringval--   --dict:11/11(L)--   --dict:6/6(L)--   setpagedevice   --dict:30/32(L)--   true
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1894   1   3   %oparray_pop   1893   1   3   %oparray_pop   1877   1   3   %oparray_pop   --nostringval--   --nostringval--   --nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   --nostringval--   1862   4   7   %oparray_pop   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1165/1684(ro)(G)--   --dict:1/20(G)--   --dict:82/200(L)--   --dict:82/200(L)--   --dict:108/127(ro)(G)--   --dict:290/300(ro)(G)--   --dict:21/25(L)--
Current allocation mode is local
GPL Ghostscript SVN PRE-RELEASE 9.00: Unrecoverable error, exit code 1

The high resolution ("-r720x720") and the high color depth ("-dcupsBitsPerColor=8 -dcupsColorSpace=1") make the CUPS raster device rendering in banding mode.

Lowering the resolution to "-r360x360" or raising the driver's cache size via

cat ~/ghostscript/gpl/testfiles/cups-does-not-show/CityMap.pdf | RIP_MAX_CACHE=1G  gs -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -r720x720 -dcupsBitsPerColor=8 -dcupsColorSpace=1 -_ > out.raster 2> log

make the file getting rendered correctly as probably Ghostscript is not using the banding mode any more.
Comment 1 Till Kamppeter 2010-07-26 14:28:14 UTC
Created attachment 6551 [details]
Offending file: CityMap.pdf
Comment 2 Till Kamppeter 2010-07-26 14:31:35 UTC
Created attachment 6552 [details]
log file of rendering CityMap.pdf
Comment 3 Till Kamppeter 2010-07-26 14:32:36 UTC
Created attachment 6553 [details]
Offending file: LGMv7a_low.pdf
Comment 4 Till Kamppeter 2010-07-26 14:33:28 UTC
Created attachment 6554 [details]
log file of rendering LGMv7a_low.pdf
Comment 5 Till Kamppeter 2010-07-26 14:34:17 UTC
Created attachment 6555 [details]
Offending file: SMP_Warwick_14.pdf
Comment 6 Till Kamppeter 2010-07-26 14:35:19 UTC
Created attachment 6556 [details]
log file of rendering SMP_Warwick_14.pdf
Comment 7 Till Kamppeter 2010-07-26 14:37:07 UTC
Rendering the same PDF files with the "png16m" output device works, also with very high resolutions.
Comment 8 Hin-Tak Leung 2010-07-26 18:21:22 UTC
BTW, there is no need to attach some of the test files - 2 of the three were checked into http://svn.ghostscript.com/ghostscript/tests/pdf/ after the last round of cups bugs.
Comment 9 Till Kamppeter 2010-07-26 22:51:28 UTC
Problem is not whether rendering is done in banding mode or in full page mode. Problem is the amount of memory made available to Ghostscript. I get the same results if I add

space_params->banding_type = BandingNever;


space_params->banding_type = BandingAlways;

or nothing to the end of the cups_get_space_params() function in cups/gdevcups.c.

If I override the cups_get_space_params() function completely by adding


in its beginning, Ghostscript determines its buffer sizes fully automatically and so it is even able to render the files with arbitrarily high resolutions and without using up the computer's memory. I tries 7200x7200 dpi and it worked (but trying to display this with rasterview actually used up the memory).

Can "/undefined in --setpagedevice--" be caused by Ghostscript not allocating memory due to a too small BufferSpace or MaxBitmap?
Comment 10 Ken Sharp 2010-07-27 08:07:46 UTC
I'm afraid I can't reproduce this. I'm running on Fedora with a freshly built HEAD, pulled this morning from Subversion. For me the specified command line completes without problem.
Comment 11 Till Kamppeter 2010-07-27 08:12:09 UTC
Ken, I am on a 64-bit system, are you on 32 bit or 64 bit?

Ken, can you try a smaller cache (driver-internal default is 8M), like:

cat ~/ghostscript/gpl/testfiles/cups-does-not-show/CityMap.pdf |
RIP_MAX_CACHE=4M  gs -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout
-r720x720 -dcupsBitsPerColor=8 -dcupsColorSpace=1 -_ > out.raster 2> log

or a higher resolution, like "-r1440x1440"?
Comment 12 Ken Sharp 2010-07-27 08:30:44 UTC
(In reply to comment #11)
> Ken, I am on a 64-bit system, are you on 32 bit or 64 bit?

> Ken, can you try a smaller cache (driver-internal default is 8M), like:
> cat ~/ghostscript/gpl/testfiles/cups-does-not-show/CityMap.pdf |
> RIP_MAX_CACHE=4M  gs -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout
> -r720x720 -dcupsBitsPerColor=8 -dcupsColorSpace=1 -_ > out.raster 2> log

This does indeed give me an error as described. Unfortunately my Linux experience is too limited for me to figure out how to reformat this in a way which I can use to debug GS.
Comment 13 Till Kamppeter 2010-07-28 10:40:05 UTC
I have looked into the source code of Ghostscript, file base/gdevprn.c, functions gdev_prn_allocate() and gdev_prn_setup_as_command_list(), and there I have seen what happens: If one does not touch the cache sizes by means of cups_get_space_params() (in cups/gdevcups.c) then gdev_prn_allocate() sets bufferSpace_is_default to "true" and therefore calls gdev_prn_setup_as_command_list() with bufferSpace_is_exact = false. This allows gdev_prn_setup_as_command_list() to double the size of the buffer space until it is big enough for the given job.

Our sample command line

cat ~/ghostscript/gpl/testfiles/cups-does-not-show/CityMap.pdf | gs -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -r720x720 -dcupsBitsPerColor=8 -dcupsColorSpace=1 -_ > out.raster 2> log

uses the following actual sizes for the buffer then:

-r720x720:       4000000
-r7200x7200:    16000000
-r72000x72000: 128000000

If cups_get_space_params() sets the BufferSpace to any non-zero value gdev_prn_allocate() sets bufferSpace_is_default to "false" and therefore calls gdev_prn_setup_as_command_list() with bufferSpace_is_exact = true and this means that the buffer size is nailed down to the given value. If the buffer space gets limited by CUPS's default setting of RIP_MAX_CACHE to 8 MB the current cups_get_space_params() gives only 800K of BufferSpace many jobs, including the attached files printed in 720 dpi and CMYK color will fail. And note that there are A0 printers, Gutenprint does 5760x2880 dpi with up to 8 inks, and numbers will get rather bigger than smaller ...

The BufferSpace is the memory size used for rendering one band when rendering in banding mode. MaxBitmap is the maximum memory size to be used for rendering in full page mode. If MaxBitmap is too small, it is automatically switched to banding mode.

What I will change is:

cups_get_space_params() will not change any values (keep Ghostscript defaults) if RIP_MAX_CACHE is not set, invalid, or zero. If the RIP_MAX_CACHE is set, it will also set the BufferSpace to RIP_MAX_CACHE and not to RIP_MAX_CACHE / 10.

I also recommend that CUPS should use either an invalid or zero RIP_MAX_CACHE or RIP_MAX_CACHE = <machine's RAM> / 4 on desktop machines and PC-like servers. The 8 MB default makes only sense for very restricted device, like routers or cell phones.
Comment 14 Till Kamppeter 2010-07-28 11:46:04 UTC
See also the thread

Sense and nonsense of RIPCache

in the cups.general newsgroup/forum on

Comment 15 Till Kamppeter 2010-07-28 14:00:18 UTC
From the Ghostscript side the problem is fixed. Now it is the task of CUPS upstream and the distributions to either set RIPCache in cupsd.conf (or the CUPS-internal default) to a reasonably high value, like 1/4 of the system's RAM or to a non-numerical value, like "auto" to use Ghostscript's dynamic memory allocation.

Marking as fixed ...
Comment 16 Till Kamppeter 2010-08-12 19:03:03 UTC
*** Bug 691046 has been marked as a duplicate of this bug. ***
Comment 17 Till Kamppeter 2010-08-12 19:07:29 UTC
*** Bug 690033 has been marked as a duplicate of this bug. ***