Some files (three so far, all produced with QuarkXPress/5.01 on Windows/XP) give "Unrecoverable error, exit code 1" at the end of the file with cups driver. Raster file is generated, and even printed by CUPS, but job is stopped. Same file with pdfwrite works fine. The system is x86_64 SuSE linux 10.1 with manually built ghostscript/8.62 and cups/1.3.7. Commands used: cups: gs -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS - sDEVICE=cups -sOutputFile=d00016-001.crs d00016-001 &>d00016-001.crs.log pdfwrite: gs -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS - sDEVICE=pdfwrite -sOutputFile=d00016-001.pdf d00016-001 &>d00016-001.pdf.log Sample file and logs are attached. It seems from log that something in cups driver is currupting stack/dictionary.
Created attachment 4198 [details] 689957.ps.gz
Created attachment 4199 [details] Logs for cups driver
Created attachment 4200 [details] Logs for pdfwriter driver
Since Ghostscript works fine on these files, we assume the problem is downstream.
I'm reopening this since I can duplicate this with head (r8825) and 8.62 with the command line: bin/gs -sDEVICE=cups -o /dev/null ./689957.ps Note that replacing cups with ppmraw does not produce an error (nor does replacing ./689957.ps with tiger.eps).
I am having this same problem on ubuntu 8.10 with cups version 1.3.9 and ghostscript version 8.63. When attempting to print photos I get the above mentioned error in the cups error_log. This behaviour is shown with both my locally attached canon printer and the cups-pdf printer.
Hmm, both gs 8.63 and gs svn-head (x64_64 linux but compiled for 32-bit) dies with Error: /undefined in tHd00016-001 , even just running with -sDEVICE=nullpage . Provue isn't cups specific? Strangely gsview in linux and win32 gsview in wine can read it the file.
There is an error message with gs-r11392 -sDEVICE=cups -o /dev/null : rangecheck; OffendingCommand: .installpagedevice
re-assign two cups bugs, having no activity from Mike Sweet for a while.
(In reply to comment #7) > Hmm, both gs 8.63 and gs svn-head (x64_64 linux but compiled for 32-bit) > dies with Error: /undefined in tHd00016-001 , even just running with > -sDEVICE=nullpage . Provue isn't cups specific? > > Strangely gsview in linux and win32 gsview in wine can read it the file. Hin-Tak, note that the attached file is gzip-compressed. You get the correct PostScript file by "gunzip"ping it.
(In reply to comment #10) > (In reply to comment #7) > Hin-Tak, note that the attached file is gzip-compressed. You get the correct > PostScript file by "gunzip"ping it. Yes, I realise that - please ignore comment 7, I think.
Rev. 11488 fixes an /invalidaccess error caused by redefined /== in the sample file. This bug appeared only with -dDEBUG flag on. The cups-specific problem is not yet fixed.
The main problem is caused by the mismatch between /cupsBitsPerColor 8 and the default value of /GrayValues , which is not adjusted when /cupsBitsPerColor is set but checked later when the page device is restored. Modifying the sample file as s|/cupsBitsPerColor 8|/cupsBitsPerColor 8/GrayValues 256| makes the file run to completion. Non-standard and duplicate page device parameters are confusing. Several approaches are possible and we need to discuss how to proceed.
Which PostScript variables (there is probably more than only /GrayValues) need to be set depending on the settings of /cupsBitsPerColor and /cupsColorSpace? /cupsBitsPerColor can be 1, 2, 4, 8, or 16. Meaning of /cupsColorSpace, according to /usr/include/cups/raster.h: typedef enum cups_cspace_e /**** cupsColorSpace attribute values ****/ { CUPS_CSPACE_W = 0, /* Luminance */ CUPS_CSPACE_RGB = 1, /* Red, green, blue */ CUPS_CSPACE_RGBA = 2, /* Red, green, blue, alpha */ CUPS_CSPACE_K = 3, /* Black */ CUPS_CSPACE_CMY = 4, /* Cyan, magenta, yellow */ CUPS_CSPACE_YMC = 5, /* Yellow, magenta, cyan */ CUPS_CSPACE_CMYK = 6, /* Cyan, magenta, yellow, black */ CUPS_CSPACE_YMCK = 7, /* Yellow, magenta, cyan, black */ CUPS_CSPACE_KCMY = 8, /* Black, cyan, magenta, yellow */ CUPS_CSPACE_KCMYcm = 9, /* Black, cyan, magenta, yellow, * * light-cyan, light-magenta */ CUPS_CSPACE_GMCK = 10, /* Gold, magenta, yellow, black */ CUPS_CSPACE_GMCS = 11, /* Gold, magenta, yellow, silver */ CUPS_CSPACE_WHITE = 12, /* White ink (as black) */ CUPS_CSPACE_GOLD = 13, /* Gold foil */ CUPS_CSPACE_SILVER = 14, /* Silver foil */ CUPS_CSPACE_CIEXYZ = 15, /* CIE XYZ @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_CIELab = 16, /* CIE Lab @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_RGBW = 17, /* Red, green, blue, white @since CUPS 1.2/Mac OS X 10.5@ */ CUPS_CSPACE_ICC1 = 32, /* ICC-based, 1 color @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICC2 = 33, /* ICC-based, 2 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICC3 = 34, /* ICC-based, 3 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICC4 = 35, /* ICC-based, 4 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICC5 = 36, /* ICC-based, 5 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICC6 = 37, /* ICC-based, 6 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICC7 = 38, /* ICC-based, 7 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICC8 = 39, /* ICC-based, 8 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICC9 = 40, /* ICC-based, 9 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICCA = 41, /* ICC-based, 10 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICCB = 42, /* ICC-based, 11 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICCC = 43, /* ICC-based, 12 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICCD = 44, /* ICC-based, 13 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICCE = 45, /* ICC-based, 14 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ CUPS_CSPACE_ICCF = 46 /* ICC-based, 15 colors @since CUPS 1.1.19/Mac OS X 10.3@ */ } cups_cspace_t;
Additional hint for fixing this bug: If the problem is caused by incomplete registering of the used color space and color depth, add the missing parts to the cups_set_color_info() function. Here is already a case structure distinguishing the different color spaces by their number of components. You probably need not to worry about strange components like gold or silver, more important is probably the number of components and the bits per pixel and color component.
Created attachment 6663 [details] patch Check for a CUPS device parameter and set the corresponding GS parameter to keep PS and C view on the page device in sync.
Rather than modifying the ghostscript gs_setpd.ps, I STRONGLY recommend that the 'hack' be implemented in gdevcups.c (even if it is more difficult). It seems that the cups device 'put_params' can check for this parameter and set the GrayValues parameter similarly to the way the gs_setpd.ps patch (HACK) does. IMHO, it's bad enough that we have 'pdfwrite' specific hacks scattered about in the PostScript layer of implementation -- we don't want to propagate this!
Alex, I am not sure due to not knowing the interpreter internals well enough, but only fitting the /GrayValues to the cupsBitsPerColor can perhaps lead to the problem only be solved for monochrome/grayscale output. If color output is selected, probably other variables (/RGBValues, /RedValues, ..., CMYKValues, ...) need to get set. For testing: Color output can be selected by setting cupsColorSpace to 1.
I ran this with the current head and there is no longer an error at the end. Ending log looks like this. -save- **** DSC comment: /Pages << /DSC_struct -dsc_data_struct- /NumPages 1 >> %%[LastPage]%% **** DSC comment: /EOF << /DSC_struct -dsc_data_struct- >> INFO: Rendering completed