universal filter generates RGB image/urf for the monochrome printer

[alexpevzner]

This is derivative from the following bug reported against CUPS: OpenPrinting/cups#804

Although hotfix for this problem exist (OpenPrinting/cups#805), the actual problem is in the cups-filters (according to @michaelrsweet, and I agree with him).

With the PPD file, autogenerated by CUPS for the Pantum BM5100ADW Series printer (see attachment), the universal filter generates RGB image/urf output instead of the Grayscale one. Printer rejects this image, which effectively breaks driverless printing on this device (and probably on many other devices with similar behaviour).

• Pantum_BM5100ADW_Series_2DFFA2.ppd.txt -- the problematic PPD, auto-generated by CUPS

Adding the following line to the PPD file fixes the situation:

*cupsUrfSupported: "V1.4,W8,IS1,CP99,PQ4,OB10,RS600,DM1"

However even without this line the generated PPD should produce monochrome image. According to @michaelrsweet:

...but the bug is in cups-filters - the ColorModel option code, when executed, specified sGray as the colorspace. And the PPD specifies ColorDevice: False...

I'm willing to spend some time investigating this problem in cups-filters, so for now I assign this issue to myself

[zdohnal]

Hi @alexpevzner ,

cups-filters nowadays is a place for filter binaries and backends for CUPS 2.x, and all logic was moved into libcupsfilters and libppd, so IMO the issue will be somewhere in those libraries.
I've reproduced the issue by running the filter by hand and the output file is in color - I see there are logs about ghostscript filter using srgb.icc profile, which might cause the issue - I will try to dig deeper once I have time.

[alexpevzner]

Hi @zdohnal,

my first suspicion was ppdFilterLoadPPDFile() from the libppd - it reconstructs a set of IPP printer attributes from the supplied PPD.

Though the itself idea perform double conversion (IPP->PPD->IPP) sounds, as for me, a little bit quirky, the reconstructed attributes looks correct. So my next suspicion is the libcupsfilters, where parameters for Ghostscript are generated from the printer attributes.

From the filter log, Ghostscript is called with incorrect parameter -dcupsColorSpace=19, must be 18 for the grayscale image.

[tillkamppeter]

Yes, this is correct, Ghostscript has to use color space 18 (sGray). So possibly the ghostscript() filter function has a bug, not getting note of that the destination color space is gray and not color. Also check whether directing the job through the alternative pdftoraster() filter function (poppler-based) causes the same problem (but if it works we still need to fix the ghostscript() filter function.

[zdohnal]

Update: ghostscript uses color profile because h.cupsColorSpace is CUPS_CSPACE_SRGB. Next I will check how the headers in the filter are generated.

[zdohnal]

Ok, I was able to track the issue down - it happens because raster_base_header() does not check whether the device supports color - the only way how to make printing work was to pass monochrome settings into job, and has cups-raster as output format. In other cases, color device was suggested.

The PR above adds check if color-supported is true and if not, sets Grayscale color spaces.

[alexpevzner]

Hi @zdohnal,

I've promised to look to this issue by myself, but so far was too busy with the preparation to the new release of goipp and ipp-usb.

Thank a lot for taking this issue to yourself!