The customer reports and I've verified that when the attached PDF file, a portion of swatch R of the file eci_altona-test-suite-v2_technical2_one-patch-per-page_x4.pdf, is rendered by Ghostscript the output is slightly different than expected (in this case expected means as rendered by Adobe Acrobat and specified in the Altona Documentation). The command line I'm using for testing: bin/gs -sDEVICE=tiff32nc -o test.tif -r300 ./altona_r.pdf
Created attachment 12646 [details] screenshot.png Screenshot showing difference (acrobat on the left, Ghostscript on the right).
Created attachment 12647 [details] altona_r.pdf
This is caused by an odd interaction of the overprint mode being set to 1 and the blend mode being set to Screen. We have an Axial shade that includes only magenta and yellow. We then draw a circle with color that has only C and M of 50% (no magenta) with screen blend mode and overprint on and overprint mode set to 1. Ghostscript is getting the yellow channel correct but the magenta channel has too much ink. Reading the spec, it is clear this image is right out of the specification in Plate 20. The description on how to handle this case is described in the Section entitled Compatibility with Opaque Overprinting. This involves the used of a special implicit blend mode when overprint and transparency is used. In particular special handling is required when the blend mode in the graphic state is not Normal. In that case, the object being painted should be treated as if it were defined in a non-isolated non-knockout transparency group and painted CompatibleOverprint Blend mode (the special implicit mode) and then the group is painted using the current blend mode in the graphic state. Ghostscript is most certainly not doing this. This really is not related to PDF X/3 support but is a more fundamental bug in Ghostscript's transparency and overprint interaction. This will take a bit of time to fix.
Commit http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=0d619ee9816662b4264f6d9ca3be0045a42a7d61 is the start of an effort to fix this. This adds in the CompatibleOverprint blend mode for use when we have transparency and overprinting enabled. Section 7.6.3 of the specification describes this. The parts that are missing are on the interpreter side. We have to add code in the interpreter side to invoke this blending mode when overprint is enabled (and transparency) and we are painting elementary graphics objects (fills, strokes, text, images, and shadings) (That is from the spec). If the blend mode is anything BUT Normal, the interpreter should push a non-isolated non-knockout group prior to painting the object. The blend mode should be set to BLEND_MODE_CompatibleOverprint. When we pop the group, the blend mode should be restored to the non-Normal blend mode for the group composition. This is what is happening (or not happening actually) with the file attached to the bug. In the attached file, the overprint mode is 1 and the blend is set to Screen. The back drop ends up blending with itself which is what should occur if we had a non-isolated group wrapped around the drawing of the circle. Assigning this to Ray as he will be completing the work on the interpreter side.
This was resolved with Michael's commit and two others. All three are: 0d619ee CompatibleOverprint blend mode addition (c-code) 82e37a2 Bug696876: Fix overprint blending when CompatibleOverprint mode not used. 093bd18 Support CompatibleOverprint in the interpreter (bug 696876) Customer may need help if these are to be applied to an older code base, but customer is currently evaluating from git HEAD, so it is OK.