Please open the ps test file in text editor. I’ve marked the setcolorspace (cs) operator by a % Here is the problem comment where an Error: /rangecheck in --@0x100826d0-- occurs. Command line: gs -r200 -sDEVICE=tiffsep -sOutputFile=%1.%%03d.tif %1 I apologize for the unreasonably big filesize but it would be difficult to cut the unneccesary parts.
Created attachment 6847 [details] ps test file
In fact, the file can be easily reduced to the following lines: [/Indexed [ /DeviceN [(PANTONE 186 U) (Black) (Dummy) (Dummy) (Dummy) (Dummy)] [/DeviceCMYK] {6 4 roll pop pop} ] 255 256 6 mul string ] setcolorspace Colorant names in DeviceN color space must be unique. Otherwise, PS interpreter needs to pick which channel to use for a non-unique colorant name. The only exception is /None color, which doesn't mark any output planes. The file should use /None or (None) instead of (Dummy).
(In reply to comment #2) > Colorant names in DeviceN color space must be unique. > Otherwise, PS interpreter needs to pick which channel to use for > a non-unique colorant name. > > The only exception is /None color, which doesn't mark any output planes. > The file should use /None or (None) instead of (Dummy). I can't find anywhere in the specification which says that the ink names need to be unique (though its clearly daft not to have them unique). The specification *does* however say on p246 of the PLRM that /None (and /All) are not allowed colours. So the test in gscdevn.c is clearly incorrect. If we are going to enforce this restriction the test should be done in validatedevicenspace in zcolor.c, not in gscdevn.c. Acrobat and Jaws both allow duplicate colour names in a DeviceN space, I think its likely that CPSI will do so too or this would have been picked up previously (the tint transform also looks like Adobe foolishness) so I think we will have to allow this too. I'm looking at patches to address these. The 'weirdness' of the message is due to the fact that the error is being returned inside a continuation procedure, I'm trying to figure out how to have it return 'setcolorspace' instead of a pointer to the function address, any ideas ?
Ken, you are right. PhotoPrint, the reference implementation does the following: If there's an unmatching colorant Use tint transform function else if colorants don't repeat Draw DeviceN color as documented in PLRM else Draw white color Regarding the continuation operator, the easiest way to get rid of the number is to register this operator under some funny name. We usually start the name with % character. This name will be printed instead of the address.
Colorants /None and /All are accepted but don't have a special meaning in DeviceN.
(In reply to comment #5) > Colorants /None and /All are accepted but don't have a special > meaning in DeviceN. Thanks Alex, I have a file which is showing a difference which I need to look at (I suspect I messed soemthing up), but otherwise its working OK. I did indeed register the continuation operators with dummy more-or-less meaningful names, which is at least better than a memory address. I found in opdef.h that the % was a internal operator name and doesn't appear in systemdict, so I used that as part of the names. I'll sort out the remaining problem tomorrow, thanks for checking the reference implementation.
Fixed in revision 11872: http://ghostscript.com/pipermail/gs-cvs/2010-October/011915.html
GS 8.71 still has problems with this file, just try the following command line gs -r240 -dNOPAUSE -dBATCH -sDEVICE=tiffsep -sOutputFile=%1.%%03d.tif %1 and watch the Citroën C3 Picasso and C4 Picasso images, they should be corrupted. The problem is even much more evident when running in debug mode and disabling compression of encoded colorant values in gdevdevn.h #define USE_COMPRESSED_ENCODING (0) .\psi\igcstr.c(153): String pointer 0x21c6b58[1024] outside [0x21c6c71..0x21c6f58) and crash. Though the problem seems to be fixed in 9.00 (or at least cannot be replicated) I would appreciate to have a patch – as StudioRIP is not ready yet to migrate on 9.00 due to incompatibilities with the new CMS. Thanks a lot in advance!
(In reply to comment #8) > GS 8.71 still has problems with this file, Do you mean there are problems after applying the patch ? The bug was reported against 9.00 which is why the patch was developed for 9.00. I didn't try 8.71 but I don't see how you can have managed to get any output from 8.71 without applying the patch for 9.00 to 8.71. If this is the case, please confirm and I will open a new issue against 8.71.
The patch was so simple as there were no obstructions to apply it on 8.71 as well (I’ve modified both gscdevn.c and zcolor.c exactly in the way the patch description showed). So the comment obviously refers to the PATCHED 8.71 version, the bug can be reopened. Thanks!
(In reply to comment #10) > The patch was so simple as there were no obstructions to apply it on 8.71 as > well (I’ve modified both gscdevn.c and zcolor.c exactly in the way the patch > description showed). > > So the comment obviously refers to the PATCHED 8.71 version, the bug can be > reopened. The bug is clearly quite different, for an earlier version of Ghostscript, and *this* issue is already resolved, even in the earlier version when using the supplied patch. Therefore I've opened a new issue for you as #691744 and added you to the CC list there.
(In reply to comment #11) > Therefore I've opened a new issue for you as #691744 and added you to the CC > list there. Thanks, Ken!