Using ghostscript-7.07 on linux with gimp-print-4.2.5, ijs driver for canon model bjc-3000. No problem processing various *.ps files, but attempts to process *.pdf files invariably fail with the following error, including pdf versions of files that have been successfully processed as *.ps: Error: /rangecheck in .installpagedevice Operand stack: --nostringval-- --dict:54/62(ro)(G)-- --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 1 3 %oparray_pop --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1076/1123(ro)(G)-- --dict:0/20(G)-- --dict:68/200(L)-- Current allocation mode is local I used the following gs options: -q -dPARANOIDSAFER -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=ijs -sIjsServer=/usr/local/bin/ijsgimpprint -dIjsUseOutputFD -sIjsDeviceManufacturer=CANON -sDeviceModel=bjc-3000 -sIjsParams=MediaType=Plain,InkType=CMYK,Quality=1440x720dpi -sOutputFile=- - I can work around the problem by reverting to the equivalent built-in stp driver for the bjc-3000.
We'll need a test file in order to try and reproduce this problem. Please attach one to this report.
Created attachment 262 [details] Pdf and ps versions of test file. Test files as requested, a pdf file and a ps version of the same created with pdf2ps. Note that I was able to reproduce the problem with several input files selected at random, so I don't believe it is specific to the file content.
I am able to replicate the problem, and have analyzed it somewhat. The rangecheck is occurring in gsijs_put_params(), in the setting of ProcessColorModel. There is a check to see whether the value of this parameter is set to a different value when the device is open. The PDF interpreter is setting it to DeviceRGB, which is considered to differ from the original (null) value. In fact, the default value for this parameter _is_ DeviceRGB, so we shouldn't be signalling a rangecheck. I think the best fix would be to add logic for a default value string. Alternatively, it might be a good idea to make the PDF interpreter not explicitly set ProcessColorValue. A workaround is to add -sProcessColorMode=DeviceRGB to the command line options.
Making this a bountiable bug since we don't have resources to address the issue. Implementation of either of Raph's suggested fixes would be acceptable.
Created attachment 1229 [details] patch Initialize ColorSpace parameter in ijs driver to DeviceRGB. This prevents a PostScript error in "currentpagedevice setpagedevice" code when ColorSpace is not explicitely initialised.
The patch is committed to HEAD and GS_8_1X branches.
New bug 688048 "ijs driver broken for ProcessColorModel=Gray between 8.50 and 8.51" due to the patch for bug 687013.
Remove dependence on bug 688048: the change here exposed a bug in previously unused code path, and is not the cause of it. Apologies.