Created attachment 10789 [details] patch to remove the -diccTransform option (and make it the default) I have looked through the bitmap diff's of the pxl testing, and concluded that most of them is unrelated to the recent changes, and those few related to the recent changes are not significant. and so here are 4 action items for Marcos. Just take your time... No hurry. 1. Here is the patch to remove the -diccTransform option. Have a look over it (well, review...). Already cluster-tested, no difference. I'll add a more detail commit message when it is time to commit. The boolean value is only just in one place (&& with "can_transform"), the rest is just reading it from command and storing it somewhere, etc. Quite simple, really. 2. Please verify my conclusions on the bitmaps being unrelated to the recent changes. The 32 bitmaps involves 16 files. In the end, I just built my local head (on top of master, which has the recent changes), and 9.14 (which has nothing of mine recent); and found that 12 of those gives identical output with both pxlcolor and pxlmono (with -diccTransform). So my new code simply had no effect on them. I am just doing plain -diccTransform -sDEVICE=pxlcolor/pxlmono without -r, and compare the md5sum's. Out of the remaining 4, Bug693398.ps, tests_private__ps_ps3cet_29-07A.PS and tests_private__ps_ps3cet_29-07B.PS differ slightly between my HEAD and 9.14, but the difference seems to be of the nature of Bug 695091 (somehow mask tiles are looked-up/cached differently and file size differs slightly, and md5sum differs, but I cannot see any bitmap difference at r300 AFAIC). T2CharString.pdf is the one with a genuine change - it is a small image in a small page size, going from rendering as small rectangles to one high-level image. Some edges in the image are off by one-line pixel in the image. 3. The 16 files - I think you have uncovered a few issues that are not recent regressions, or even regression at all. You probably should file some of them. I had a quick look, but since most of them have same md5sum when tested against 914, obviously I didn't spend much time on it, so any opinion of mine on that 12 should be taken with a pinch of salt... T2CharString.pdf - already mentioned tests_private__ps_ps3cet_29-07A.PS, tests_private__ps_ps3cet_29-07B.PS - image edge 1-pixel differences Bug693398.ps - you already filed Bug 694741 for it. jointest.ps, Bug688655.ps - seems to some kind of accuracy/grid position problem. 692356_-_inefficient_dashing.pdf - it seems that pcl6 does not like zero-length dashes... as far as I see it is not illegal in pxl, though it seems to be illegal in postscript. pxl can probably be persuade not to emit those, or pcl6 to accept those... Bug691625.ps, Bug691778.ps, Bug692174.pdf, fts_06_0626.pdf - "missing" output. It is not missing, but pxl seems to be doing white on white. It took me somewhere strange in the 1-bit memory device trying to do ROPs. (Robin's code in 2011, I think). I could be wrong, but these seem to be one and the same problem anyway and can be tackled together. Bug688580.ps - missing star - it could be part of the above 4, or something else. Bug692217.pdf - quite major gray-shade difference. Bug692251.ps - there is a red-line at the edge (where nothing is) - is this small disagreement about paper dimension? Bug692494.pdf - I think I have seen something out of curiosity like this (part of an image turns its complement color) in a report, but I cannot find it now. The closest I find is "Bug 694605 - Differences in color with and without banding", but I remember having seen some sort of comparison of two rendering where the bottom left portion of page has a green background vs an orange background... I think it was a bug under either Michael or Henry. Bug692666.pdf - border blacked out. Not much idea. So that 16 of them. I suggest somebody work on "Bug 694741" first, since it has already some info and a range to bisect on... and the 4 missing outputs. Some of the rest might go away when those two are solved... 692356_-_inefficient_dashing.pdf should go to Henry. Issues need to file, etc. 4. Did you somehow compare gray output with gray output, and get gray difference, instead of red-hight-lighted ones? So that's all, 4 action points.
(In reply to comment #0) > jointest.ps, Bug688655.ps - seems to some kind of accuracy/grid position > problem. Just look at the original bug reports about how these files are special, I see Bug 688655 - stroking: Incorrect stroking of very wide curves. part of the bitmap looks a bit like this: http://bugs.ghostscript.com/attachment.cgi?id=5487 (from that report). It is worth noting that PCL XL does not support of the full range of postscript line joins. (only 0, 1, 2, 3 - I think ps can go up to 5 or 6?). Line 1236, gs/devices/vector/gdevpx.c - "Igoring invalid linejoin enumerator %d\n" though this code wasn't triggered. In any case, it is possible that this issue (I don't think it is a regression) is that PXL is a high-level vector device, but does not support all the features of postscript, especially about paths and joins.
(In reply to comment #0) > Bug692217.pdf - quite major gray-shade difference. The noted difference with -sDEVICE=pxlmono is entirely due to with/without -r300. It should go to Michael or Ray and probably should be looked at together with "Bug 694605 - Differences in color with and without banding"
(In reply to comment #0) > Bug692494.pdf - I think I have seen something out of curiosity like this > (part of an image turns its complement color) in a report, but I cannot find > it now. The closest I find is "Bug 694605 - Differences in color with and > without banding", but I remember having seen some sort of comparison of two > rendering where the bottom left portion of page has a green background vs > an orange background... I think it was a bug under either Michael or Henry. > > Bug692666.pdf - border blacked out. Not much idea. Bug692666.pdf with pxlmono turn out to be also due to difference between banding or not, also, i.e. with or without -r300 . But Bug692494.pdf is *not* about banding.
(In reply to comment #2) > (In reply to comment #0) > > Bug692217.pdf - quite major gray-shade difference. > > The noted difference with -sDEVICE=pxlmono is entirely due to with/without > -r300. > > It should go to Michael or Ray and probably should be looked at together with > "Bug 694605 - Differences in color with and without banding" Bug692217.pdf itself actually already has a bug about banding vs no banding: "Bug 694973 - Wrong colors when using clist with comparefiles/Bug692217.pdf"
(In reply to Hin-Tak Leung from comment #4) > Bug692217.pdf itself actually already has a bug about banding vs no banding: > "Bug 694973 - Wrong colors when using clist with comparefiles/Bug692217.pdf" new bug filed comparefiles/Bug692217.pdf, "Bug 695278 - Significant color differences in banded vs. page mode." probably should be counted as duplicate of the clist problem bug 694973 .
An update: while adding cmyk support to the pxl driver, I see that -diccTransform - or rather, the underlying main working routine, gscms_transform_color_buffer() - does not work correctly when -dUseFastColor is also specified. I think maybe "use colour management (in gscms_transform_color_buffer() )" and "do not use colour management (-dUseFastColor)" are fundamentally incompatible, or in any case, does not work correctly at the moment. The impact of this finding is that, there are users (Artifex clients) for which -dUseFastColor is important and who seems to be routinely using it. Therefore this "bug report" should not be processed, until the conflict or compatibility issue with -dUseFastColor, is addressed. i.e. DO NOT PROCEED ON THIS, until further notice.
Passing to Henry to have a look.
This option is still nor removed.