The following two command generate a final image with different colors for a portion of page 8 (see the screenshot.png file attached): gs/bin/gs -sDEVICE=pxlcolor -o test.pxl ./Bug693398.ps main/obj/pcl6 -sDEVICE=ppmraw -o test1.ppm ./test.pxl gs/bin/gs -sDEVICE=ppmraw -o test2.ppm -r72 ./Bug693398.ps Note that gs910 and earlier versions generate output that is different than the current master (184dcfd570a96328798e36d8e08495eb426d67f9) but is not correct either.
Not sure about the 'page 8' part, but attachment 9033 [details] of Bug 693398 (a single page ps file) indeed shows significant difference. If I were to guess, it is probably pclxl_strip_copy_rop() - it is still wrong but only about 4 files uses the wrong part of the code path (the "return 0" part). There is a bug opened for it (bug 693056) but it was closed "LATER". One simple way to verify this as duplicate of 693056 is to add a message display just before the "return 0". (http://bugs.ghostscript.com/show_bug.cgi?id=690585#c14) and see if one is emitted. The wrong color parts look like some sort of reverse - light orange to dark green, orange to green. I am not able to see obvious difference between 8f491ec1493bcb11583d450a264a1b80d5557217 (3 commits after (184dcfd570a96328798e36d8e08495eb426d67f9) and gs910 though.
Oh, I see, you mean page 8 of attachment 9014 [details] in Bug 693398. Holly - indeed it is rather wrong, and different between 910 and git head. My guess on pclxl_strip_copy_rop() still stands.
Have a little look, this problem has nothing to do with bug 693056. Also have some old snapshot binaries around - e9b4752 shows the same look as 9.10 (probably not very surprising since it is only a commit or two away from 9.10). There is only about 120 commits between that and current head so should be quite bisect'able. Though, since neither are correct, it is only of interest if the change helps to fix the problem.
bisected through, the most recent change in outcome was: commit 38ed5ffaf81405a3e8ff094afbc2ada05eaf630c Author: Michael Vrhel <michael.vrhel@artifex.com> Date: Tue Oct 22 11:09:23 2013 -0700 Fix for bug in case where alternate color space for DeviceN and separation is CIE If the CIE color space has a range different than 0 to 1 we need to rescale before using the equivalent ICC profile. Fixes bug 694731. Note diffs for 09-34.PS match what is created by Distiller and AR vers. X. As noted earlier, neither before or after this commit are correct. Also, 9.10 is slightly different from before also. That occurred between 9.10 and f39d982 . So there are at least 3 differently incorrect renderings.
This problem still occurs in the current master branch.
Peter re-tested this, but it looks like (from comment #5) that this was affected by (not fixed, however) by commit 38ed5ffaf8 so possibly Michael should have a look. Note that this may be also be affected by -diccTransform which the long time pending patch for bug 695124 would make default to true.
The original report is fixed with this commit: 7bb18cef151732eccbdb808d8e261a0057d78c2d
Hmm, most "colour wrong" matters can be solved by turned them back to little trapezoids, but at the expenses of increase in output size (sometimes quite a lot 10x/20x). A better answer is to make the -diccTransform option fully correctly in all situations, and make it the default. It is supposed to apply the necessary icc transform for rotated images to make them colour correct, without increasing file size too much.