Bug 688320

Summary:	pxlcolor produce unusable output
Product:	Ghostscript	Reporter:	Baoshi Zhu <bszhu>
Component:	Printer Driver	Assignee:	Henry Stiles <henry.stiles>
Status:	RESOLVED FIXED
Severity:	normal	CC:	htl10
Priority:	P3
Version:	8.51
Hardware:	PC
OS:	Windows XP
Customer:		Word Size:	---
Bug Depends on:
Bug Blocks:	690069
Attachments:	The attached PS file produces invalid PCL stream. The PS file is generated by Microsoft Word.

Description Baoshi Zhu 2005-10-03 00:08:29 UTC

The pxlcolor driver sometimes outputs unusable output of images. The output is
"ExtraData" by HP printer and also by GhostPCL. A look into the PCL6 stream
finds that the ReadImage operator is fed with extra data, e.g., the page
colorspace is eGray, the image is e8Bit and 8x1 pixels large, but the ReadImage
is fed with 24 bytes instead of 8 bytes.

Comment 1 Baoshi Zhu 2005-10-03 00:09:56 UTC

Created attachment 1708 [details]
The attached PS file produces invalid PCL stream. The PS file is generated by Microsoft Word.

The attached file will reproduce the bug.

Comment 2 Marcos H. Woehrmann 2007-10-15 00:00:36 UTC

Here is a possible solution to the problem (I'll wait for comments on the fix
for bug 689479 before committing):

--- src/gdevpx.c        (revision 8290)
+++ src/gdevpx.c        (working copy)
@@ -1291,6 +1291,12 @@
     if (code < 0)
        return code;
     source_bit = sourcex * dev->color_info.depth;
+
+    if (dev->color_info.num_components == 1)
+        pclxl_set_color_space(xdev, eGray);
+    else
+        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);

Comment 3 Hin-Tak Leung 2009-10-18 19:12:38 UTC

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);

Comment 4 Hin-Tak Leung 2009-10-27 11:33:10 UTC

My simplier version of the fix plus a one-line comment about side effect of
previous gray fill/stroke, committed as r10233 .

Verified the reported file as broken before, and ok after with pcl6.