| 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 driver | Assignee: | Till Kamppeter <till.kamppeter> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alex, ken.sharp, mike, ray.johnston, regisr, twaugh |
| Priority: | P4 | ||
| 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 |
||
Created attachment 6551 [details]
Offending file: CityMap.pdf
Created attachment 6552 [details]
log file of rendering CityMap.pdf
Created attachment 6553 [details]
Offending file: LGMv7a_low.pdf
Created attachment 6554 [details]
log file of rendering LGMv7a_low.pdf
Created attachment 6555 [details]
Offending file: SMP_Warwick_14.pdf
Created attachment 6556 [details]
log file of rendering SMP_Warwick_14.pdf
Rendering the same PDF files with the "png16m" output device works, also with very high resolutions. 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. 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; or 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 return; 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? 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. 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"? (In reply to comment #11) > Ken, I am on a 64-bit system, are you on 32 bit or 64 bit? 32-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. 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. See also the thread Sense and nonsense of RIPCache in the cups.general newsgroup/forum on http://www.cups.org/newsgroups.php?s21126+gcups.general+T1 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 ... *** Bug 691046 has been marked as a duplicate of this bug. *** *** Bug 690033 has been marked as a duplicate of this bug. *** |
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.