The following files are rendered with portions of the page with the wrong colors when using the pxlcolor device: 18-02A.PS 18-02G.PS Command lines used for testing: gshead -sDEVICE=pxlcolor -r600 -o test1.pxl ./$1 pclhead -sDEVICE=ppmraw -r600 -sOutputFile=viapxl.ppm -dNOPAUSE ./test1.pxl gshead -sDEVICE=ppmraw -r600 -o direct.ppm ./$1
Created attachment 5583 [details] 18-02A.PS.0.png
I think it was 18-02G.PS, when I worked out it is copy_color misbehaving, I tried switching it back to gx_default_copy_color(), and gx_default_copy_color() not only generates the correct color, but the output file size is also only 1/2 of what pclxl_copy_color() is currently doing. So that's a workaround (and an incredibly good one), until I figure out what's wrong with pclxl_copy_color().
The B/W version of this bug is 688992 (which was fixed with a by-pass to gx_default_copy_* as was possible with this bug as mentioned in comment 2). But I am going to fix it by making pclxl_write_image_data() handling full byte offsets as suggested in http://bugs.ghostscript.com/show_bug.cgi?id=688992#c8 . The reason why gx_default_copy_* can be more efficient than pclxl_copy_* is because SetBrush/Retangle is about 1/3 of the size of setCursor/beginimage/readimage/endimage, so for rectangles below about 3 pixels, it is more efficient to use the gx_default_* routines than the pclxl_* ones.
Created attachment 5654 [details] make data_bit offset work properly. This is another bug where the person who wrote the pxlcolor/pxlmono knew about the possibility of such problem and wrote a short cryptic comment behind. The meaning of the comment only becomes obvious when the bug is fixed - there is a comment which says: /*** IGNORES data_bit ***/ and all that the patch does, is *not* to ignore the data_bit, in a nutshell.
I like the expression from Comment #4: "The meaning of the comment only becomes obvious when the bug is fixed." My goal is to make that true for all my comments.
The patch above in comment 4 was committed as r10313, 'handles the case of data_bit being multiple of 8'.