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