Return to List
Login to Post Comment
Some supporting information from the March 27, 2025 IPP WG conference call: - The problem isn't limited to CMY-only printers. Many photo printers have multiple black colorants (gray, light gray, light light gray, photo gray, matte gray, etc.), and sometimes those colorants are media-specific or do not mix well with other colors (e.g. pigment K but dye CMY). - 'monochrome' requests shades of a single color (such as black) using 1 or more colorants - 'auto-monochrome' requests shades of a single color (such as black) using the best/optimal colorants for the media, other Job Template attribute values, and document data (e.g. black text vs. grayscale photos have different needs) - 'process-monochrome' requests shades of a single color (such as black) using 2 or more colorants Members also asked about how to support less common colorants such as white which can be used as a primary colorant (e.g. white printing for T-shirt transfers) and/or as an undercoating/base coat when printing color on a dark material/media. There is also the potential for special/vendor-specific color transforms ("blueprint mode"). Finally, there should be some clarification about how this interacts with different document formats - normally Clients sending PWG Raster documents will choose the appropriate color space but, for example, "print-color-mode" could force RGB raster data to be output as grayscale, just as JPEG and PDF files containing color content can be output as grayscale.
More specifically, there needs to be a discussion of whether 'monochrome' ought to be listed by a CMY printers (it should) and how clients might handle printers that have different combinations of 'auto-monochrome', 'monochrome' and 'process-monochrome'. It could but I don't know that that gets us to where we want to be. There are basically two levels to this issue. One is for the printer to list its job option capabilities as completely and correctly as possible, and another is how different clients interpret those capabilities and also how their developers have chosen to expose, or not expose, those capabilities to the user. A Printer that has multiple marking agents could expose its single-color modes in various ways: "print-color-mode-supported" = 'monochrome' "print-color-mode-supported" = 'monochrome', 'process-monochrome' "print-color-mode-supported" = 'process-monochrome' "print-color-mode-supported" = 'monochrome', 'process-monochrome', 'auto-monochrome' Some clients might adopt a UX strategy to show all of these to the user as separate options, but is that a good idea? Or should the client instead be encouraged to show just some of them? Some clients might want to show selectable options for all supported keywords, but might want to restrict the list of options for CMY printers that don't support K. What should a client do in this case? Look at "printer-supply"? Other clients will show 1 selectable option for any of those cases above and choose to send a keyword based on internal heuristics, to avoid forcing the user to read and learn additional options.
CMY only printers aren't clearly discussed in 6.2.3, nor is the meaning of 'monochrome' when the printer has one marking agent that is NOT black. Consider these issues and expand the definition in a way that is backwards compatible.