Bug 690314

Created attachment 4823 [details]
PCL-XL testfile from Quality Logic

Created attachment 4824 [details]
rectangle_not_filled_with_light_grey.xl

simplified testfile (PCL-XL), 1 page with a rounded_rectangle on it.
Interior of rectangle should be light-grey (from RGB blue) when printed with
x11mono device.
On x11 device it's light-blue!!

The X11 devices are developer tools and don't undergo careful testing, I don't
know of any customers using them.  The pbmraw device seems to work okay and I
guess the other mono devices are working, so I am changing this to P4.

I tried with the pngmono device and this indeed did print ok.
However, our own device (derived from the gdevbit.c (mono) does not.
If compiling with the attached gdevbit.c (which generates a sunrasterfile), you
see that the fill is with black i.s.o. a halftone.
Add the $(DD)bit.dev to the DEVICES_DEVS (in pcl6_gcc.mak) and using the
following commandline:

main/obj/pcl6 -sDEVICE=bit sOutputFile=ras_%d.ras c1.xl you get the output as in
attached rasterfile (bitmono.ras) viewable with irfanview on a PC.

For reference I attached also the png16m and pngmono output.

Created attachment 4845 [details]
gdevbit.c

modified gdevbit.c (to generate a sunraster file)

Created attachment 4846 [details]
bitmono.ras

resulting sunrasterfile from command:

main/obj/pcl6 -sDEVICE=bit -sOutputFile=bitmono.ras c1.xl

Created attachment 4847 [details]
pngcolor.png

resulting color.png  with command:

main/obj/pcl -sDEVICE=png16m -sOutputFile=pngcolor.png c1.xl

Created attachment 4848 [details]
pngmono.png

resulting mono.png file with command:

main/obj/pcl6 -sDEVICE=pngmono -sOutputFile=pngmono.png c1.xl

I am copying in Ray because your gdevbit.c does not have support for his latest
changes, I don't know if that is an issue.  As for the bit device, you can
simply put a pnm header on the bit output.  "P4" followed by the width and
height of the bitmap.  Have a look at the output of -sDEVICE=pbmraw.  Finally
this doesn't look like a pcl problem so I'll assign back to support, but make it
P2 since it looks like a real problem.

Created attachment 4903 [details]
690314-bit.pbm

I cannot reproduce the problem. It looks to me like the bit device is working
correctly.

This file was created (from attachment #4824 [details]) with:

obj/pcl6.exe  -r72 -dGrayValues=2 -sDEVICE=bit -sOutputFile=x.bit
bug_690314.pxl
cat header.pbm x.bit > 690314-bit.pbm

Where 'header.pbm' contains the three lines:
P4
595 842
1

Norbert confirmed that the colors are correct as I tested, but he found that the
problem only occurs in clist mode. This test shows the wrong colors:

obj/pcl6.exe -sDEVICE=pbmraw -dMaxBitmap=10000 -sOutputFile=x.pbm bug_690314.pxl

Adding -dMaxBitmap=10000 forces banding mode. Assigning to myself as a clist
issue.

Thanks to Norbert for figuring out what allowed this to be reproduced.

This was broken by the rev 2925 DeviceN commit (massive collection with NO
detailed reasoning).

The palette colors should not be set up on the basis of color_info.polarity
since even when black is color 1 it is technically an 'additive' colorspace
("0 setgray" is black and "1 setgray" is white).

All of the other places that set this were correct. This was only broken in
clist mode since page buffer mode set this up from base/gdevmr1.c in
"mem_mono_strip_copy_rop" correctly.

The patch:

--- base/gdevmem.c      (revision 9604)
+++ base/gdevmem.c      (working copy)
@@ -168,9 +168,11 @@
        dev->cached_colors = target->cached_colors;
     }
     if (dev->color_info.depth == 1) {
-       gdev_mem_mono_set_inverted(dev,
-                                  (target == 0 || 
-                                    dev->color_info.polarity ==
GX_CINFO_POLARITY_SUBTRACTIVE));
+       gx_color_value cv[3];
+
+       cv[0] = cv[1] = cv[2] = 0;
+       gdev_mem_mono_set_inverted(dev, (target == 0 ||
+                                  (*dev_proc(dev, map_rgb_color))((gx_device
*)dev, cv) != 0));
     }
     check_device_separable((gx_device *)dev);
     gx_device_fill_in_procs((gx_device *)dev);

is committed in rev 9621.