[gs-bugs] [Bug 688320] pxlcolor produce unusable output

[bugs.ghostscript.com-bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=688320





------- Additional Comments From htl10 at users.sourceforge.net  2009-10-18 19:12 -------
Encountered this issue - actually the patch in comment 2 can be a little
simplier - because pclxl_set_color_space(xdev, eGray) is no-ops when this code
is run as pxlmono.

The bug (and the related bug 689479) is this: when run as pxlcolor, setFillColor
 and setStrokeColor can have the side effect of issuing a setColorSpace eGray
(when the fill/stroke color is a shade of gray). So this confuses the printer if
the color space isn't reset back to eRGB when a beginimage/copy_color() is later
emitted. The fix to bug 689479 only covers *some* such cases, which overlaps (is
a subset of?) this one. In any case, this one is needed and a bit earlier in the
code path. If this one is applied, the fix to bug 689479 becomes (sometimes?)
no-ops, I think, because set_color_space does not emit PCL XL instruction if an
earlier set_color_space of the same kind is in place. 

For completeness, just in case in some very strange situation, one ever
encounter a non-gray fill/stroke in a gray color space and needs that reset to
eGray for monochrome images, pclxl_copy_mono() probably should have a similiar
but opposite code inserted.

--- src/gdevpx.c        (revision 8290)
+++ src/gdevpx.c        (working copy)
@@ -1291,6 +1291,9 @@
     if (code < 0)
        return code;
     source_bit = sourcex * dev->color_info.depth;
+
+    if (dev->color_info.num_components == 3)
+        pclxl_set_color_space(xdev, eRGB);
+
     if ((source_bit & 7) != 0)
        return gx_default_copy_color(dev, base, sourcex, raster, id,
                                     x, y, w, h);





------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.