Bug 690862

Summary: pxlcolor: wrong colors
Product: Ghostscript Reporter: Marcos H. Woehrmann <marcos.woehrmann>
Component: PXL DriverAssignee: Hin-Tak Leung <htl10>
Status: RESOLVED FIXED    
Severity: normal Keywords: bountiable
Priority: P4    
Version: 0.00   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: make data_bit offset work properly.

Description Marcos H. Woehrmann 2009-10-29 11:01:06 UTC
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
Comment 1 Marcos H. Woehrmann 2009-10-29 11:01:56 UTC
Created attachment 5583 [details]
18-02A.PS.0.png
Comment 2 Hin-Tak Leung 2009-11-10 09:51:12 UTC
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(). 
Comment 3 Hin-Tak Leung 2009-11-10 17:55:56 UTC
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. 
Comment 4 Hin-Tak Leung 2009-11-10 19:35:42 UTC
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.
Comment 5 Marcos H. Woehrmann 2009-11-10 20:51:18 UTC
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.
Comment 6 Hin-Tak Leung 2009-11-23 18:10:56 UTC
The patch above in comment 4 was committed as r10313, 'handles the case of
data_bit being multiple of 8'.