In a user's bug report on driverless IPP printing it turned out that the user has a monochrome laser printer which understands only PCLm (perhaps also another, proprietary protocol but for driverless printing the only option is PCLm). See https://github.com/apple/cups/issues/6022 The printer is the HP LaserJet M15. On my investigations I found out that PCLm does not only support 8-bit-per-color RGB but also 8-bit grayscale. The PCLm specification inside the specification of Wi-Fi Direct Print (I did not find a separate PCLm specification) says: ---------- 4.2.6 Color Spaces PCLm devices support a limited set of device independent grayscale and RGB color spaces. The particular color space utilized on a given page will depend on the page content. If the page contains any color then the color space used for rendering and delivery of the page shall be DeviceRGB. If the device is color but the page contains no color content then the Client should render the page in gray-space to reduce processing time on the device as well as improve compression ratios. It is permissible for a job to contain pages composed in RGB color space as well as grayscale. However, it is not advisable to mix different types RGB color spaces on the same page, as color fidelity issues will most likely be visible. Monochrome devices shall support all RGB color spaces and color-convert the RGB source data to grayscale within the printer. During the IPP device capabilities query, the monochrome device will be able to specify the preferred color space and Clients should honor this request. The following color models are supported on PCLm version 1.0: - DeviceRGB, 8 bits-per-pixel, specified in interleaved RGB triplets. - DeviceGray, 8 bpp additive gray format ---------- In the Ghostscript implementation ("pclm" output device) I did not find a way to switch to 8-bit grayscal, and on https://www.ghostscript.com/doc/9.55.0/Devices.htm#PDFimage it is told that "pclm" only supports 8-bit RGB. Getting at least the output converted to grayscale (to print grayscale on color printers) I have simply applied a grayscale color profile with "-sOutputICCProfile=sgray.icc" and with this hit (and reported) the bug https://bugs.ghostscript.com/show_bug.cgi?id=705014 Could a grayscale mode be added to "pclm"? Should not be a lot of code needed as there us already a "pdfimage8" output device.
(In reply to Till Kamppeter from comment #0) > On my investigations I found out that PCLm does not only support > 8-bit-per-color RGB but also 8-bit grayscale. The PCLm specification inside > the specification of Wi-Fi Direct Print (I did not find a separate PCLm > specification) says: Do you have a URL where we can download the specification ? > ---------- > 4.2.6 Color Spaces > > PCLm devices support a limited set of device independent grayscale and RGB > color spaces. The particular color space utilized on a given page will > depend on the page content. If the page contains any color then the color > space used for rendering and delivery of the page shall be DeviceRGB. If the > device is color but the page contains no color content then the Client > should render the page in gray-space to reduce processing time on the device > as well as improve compression ratios. It is permissible for a job to > contain pages composed in RGB color space as well as grayscale. However, it > is not advisable to mix different types RGB color spaces on the same page, > as color fidelity issues will most likely be visible. Monochrome devices > shall support all RGB color spaces and color-convert the RGB source data to > grayscale within the printer. During the IPP device capabilities query, the > monochrome device will be able to specify the preferred color space and > Clients should honor this request. > > The following color models are supported on PCLm version 1.0: > > - DeviceRGB, 8 bits-per-pixel, specified in interleaved RGB triplets. > > - DeviceGray, 8 bpp additive gray format > ---------- My reading of this is that this is an optimisation, when the input only contains grayscale marking operations then the output can be in 8-bit gray. If there are any non-grayscale marks then the output should be in 24-bit RGB. The pages should not mix modes on the same page. In general we cannot tell whether the input makes any marks in RGB or non-grey colour spaces, which is why we choose to produce RGB output. In particular "Monochrome devices shall support all RGB color spaces and color-convert the RGB source data to grayscale within the printer" Appears to me to be quite clear, the printer should take care of this, there is no need (beyond performance optimisation) to send grayscale output to the printer. So if this is a complaint that our RGB output doesn't work on a particular monochrome printer, then I think the printer is at fault, not us. So is this meant to be a bug report, or an enhancement request ? I don't see this as a bug in Ghostscript's PCLm device, it is behaving as expected and according to the specification. On the other hand, as an enhancement, I don't think it is unreasonable for use to provide a 'pclm8' device which only produces gray scale output. I don't think it is feasible for us to produce a device which switches between 8 and 24-bits depending on the input though.
I intended it actually more a feature request than a bug report, to get better performance on monochrome printers or to allow switching to monochrome printing on color printers. I do not want to ask you to analyse every page to decide whether it should be printed in 8-bit Gray or in 8-bit RGB. Having an extra "pclm8" device for grayscale printing is good enough here. Otherwise I am comfortable with sending RGB to a monochrome printer (if Ghostscript does not crash when the gray color profile is used).
A new pclm8 device has been added in this commit: https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=6fadd95c332c349232510ed2aa47b8fac3ba5b63 The documentation has been amended to acknowledge its existence and note that it is an 8-bit gray device only. I've run some files through the device and it seems OK, in addition it shares practically all it's code with the existing pclm device, but I can't claim this is well tested.
Thank you very much. Will this make it into Ghostscript 9.56.0?
(In reply to Till Kamppeter from comment #4) > Thank you very much. Will this make it into Ghostscript 9.56.0? Not my decision but given we're already on RC2 I would have to guess that it will not.
Apparently the code has been pulled over to the release branch already so I'm wrong, it will be in the 9.56.0 release, unless something goes awry. It will not be in 9.56.0 RC2 though, the build had already been done before I committed the code.