Created attachment 8721 [details] image with (Black) (PANTONE 265 C) (None) (None) (None) If an image is set in a DeviceN colorspace, gs seems to have problems when the DeviceN contains colors other than process colors. If I use acrobat X to create a pdf from it, the output is as I would expect it.
Created attachment 8722 [details] image with (Black) (GWG Green) (None) (None) (None) another testcase
Created attachment 8723 [details] image with (Cyan) (Black) Image with DeviceN and only process colors, this looks fine
The tint transform function in the /DeviceN color space used in the 1st 2 files is clearly incorrect. [/DeviceN [(Black) (PANTONE 265 C) (None) (None) (None)] [/CIEBasedABC << /RangeABC [0 1 0 1 0 1] /DecodeABC [{100 mul 16 add 116 div} bind {0.51 mul -0.256 add } bind {1.275 mul -0.64 add } bind] ... >> ] { 5 3 roll pop pop % 3 -1 roll 100.000000 mul 0.000000 add % 3 -1 roll 255.000000 mul -128.000000 add % 3 -1 roll 255.000000 mul -128.000000 add } ] After commenting out spurious scaling, the DeviceN image renders correctly. I don't know why Acrobat Distiller is not sensitive to this bug. There's something strange with the gradient too, but Ghostscript matches Distiller in this respect. So I didn't look into this problem further.
(In reply to comment #3) Thanks for Your hint, Alex. It wasn't such easy, because the tint transform function wasn't generated but read from the PDF source, but now I was able to solve it in concatenating an invert function. I also changed RangeABC and DecodeABC, so the actual postscript code is now: [/DeviceN [(Black) (PANTONE 265 C) (None) (None) (None)] [/CIEBasedABC << /RangeABC [0 100 -128 127 -128 127] /DecodeABC [{16 add 116 div} bind {500 div} bind {200 div} bind] ... >> ] { 5 3 roll pop pop 3 -1 roll 100.000000 mul 0.000000 add 3 -1 roll 255.000000 mul -128.000000 add 3 -1 roll 255.000000 mul -128.000000 add 3 -1 roll 100 div 3 -1 roll 128 add 255 div 3 -1 roll 128 add 255 div } ] Okay, it looks confusing, but I find no other way! And Ghostscript now matches the Distiller output.
Thomas, did you check the tint transform in the PDF? To establish for sure that this isn't a problem with poppler's emitting of the tint transform?
(In reply to comment #5) > Thomas, did you check the tint transform in the PDF? To establish for sure that > this isn't a problem with poppler's emitting of the tint transform? Yes, I checked it in the debugger, that was the first I'd done. You can proof it, the attached EPS were produced by the freely available patches from the Ghent PDF workgroup, 08_DeviceN patches: 128 0 obj[/Indexed 129 0 R 255 136 0 R] endobj 129 0 obj[/DeviceN[/Black/PANTONE#20265#20C/None/None/None]130 0 R 132 0 R 133 0 R] endobj 130 0 obj[/Lab<</BlackPoint[0.0 0.0 0.0]/WhitePoint[0.9642 1.0 0.82491]/Range[-128.0 127.0 -128.0 127.0]>>] endobj 131 0 obj 65 endobj 132 0 obj<</Length 131 0 R/FunctionType 4/Filter/FlateDecode/Domain[0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]/Range[0.0 100.0 -128.0 127.0 -128.0 127.0]>>stream :: decoded: { 5 3 roll pop pop 3 -1 roll 100.000000 mul 0.000000 add 3 -1 roll 255.000000 mul -128.000000 add 3 -1 roll 255.000000 mul -128.000000 add } endstream endobj 133 0 obj<</Colorants 134 0 R>> endobj 134 0 obj<</PANTONE#20265#20C 116 0 R>> endobj 136 0 obj<</Length 1183/Filter/FlateDecode>>stream << lookup table >> endstream endobj
The fragment of the PDF file looks reasonable but the generated EPS isn't. In any case this is not a Ghostscript bug.