[Printing-architecture] Make use of extended color spaces on IPP printers

Till Kamppeter till.kamppeter at gmail.com
Tue May 25 17:43:55 UTC 2021

I have now committed my first approach of auto-selection of the color 
space and depth in cups-filters:

Here is the commit:


The basic principles are:

- Depending on the output format (PWG or Apple Raster) the printer IPP
   attribute pwg-raster-document-type-supported or urf-supported is used
   to determine which color space/color depth combos are available.
- A color space of sGray, sRGB, AdobeRGB, Device... is selected
   depending on input data, presence of a custom ICC profile, desire to
   print in color, gray, or bi-level (print-color-mode job attribute).
- If the requested color space is available it gets selected, otherwise
   the default color space is chosen: For color printing (or if no mono
   color space is available) AdobeRGB if available otherwise sRGB, for
   mono printing sGray.
- Within the selected color space the lowest color depth (usually 8 bit
   per color) is chosen, if print-quality is set to "high" the highest
   color depth (16-bit if available).

My commit implements this only for the ghostscript() filter function 
(gstoraster CUPS filter) for now, but commonly used code is in separater 
library function so other filter functions are easy to update, too.

This is implemented for both using the filter function PPD-less, based 
on printer and job IPP attributes and as CUPS filter with a PPD file 
generated by the PPD generator of libcupsfilters (for example via the 
"driverless" utility) for a driverless IPP printer.

The generated PPD files are appropriately changed, by including both 
pwg-raster-document-type-supported and urf-supported IPP attributes of 
the printer as PPD attributes ("*cupsPwgRasterDocumentTypeSupported" and 
"*cupsUrfSupported") and by the "ColorModel" option now mirroring the 
print-color-mode IPP attribute, listing the choices from 
print-color-mode-supported, and not including pseudo-PostScript code any 
more as these parameters now get auto-selected by the filter. Formerly, 
the PPD generator created one "ColorModel" choice for each color 
space/depth combo for manual selection.

The ghostscript() filter function currently does not pre-check the 
content of incoming PDF files for best choice of color space, the color 
space requested from the color space selector function 
(cupsRasterSetColorSpace() in cupsfilters/raster.c) is always the 
default color space. Only if there is a custom color profilea Device... 
color space is requested.

Ghostscript is called with both "-dUsePDFX3Profile" and 
"-sOutputICCProfile=..." where Ghostscript's standard ICC profiles for 
sGray, sRGB, and AdobeRGB are used if no custom profile is specified.

There is most probably room for improvement, any hints are welcome.

Also more filter functions (...toraster) will be moved over.


On 07/05/2021 20:52, Till Kamppeter wrote:
> TL;DR: Some doubts about supporting extended color depth and color spaces:
>   - How to discover if a page in a PDF is 8/16-bit color/grayscale
>     sRGB/Adobe RGB?
>   - How important is Adobe RGB for printing? If a printer advertises that
>     it supports it, is it worthwhile for us to support jobs in Adobe RGB?
>   - How is all this influenced by the "print-content-optimize" setting?
> I want to make it possible to make use of the support for extended color 
> spaces of driverless IPP printers (or Printer Applications).
> IPP allows the user to only select from the following color modes for a 
> job (list taken from PAPPL, actually available modes advertised in the
> "print-color-mode-supported" IPP attribute):
>    'auto'               - Automatic color/monochrome print mode
>    'auto-monochrome'    - Automatic monochrome/process mono print mode
>    'bi-level'           - B&W (threshold) print mode
>    'color'              - Full color print mode
>    'monochrome'         - Grayscale print mode using 1 color
>    'process-monochrome' - Grayscale print mode using multiple colors
> On mono/grayscale printers there is no 'auto-monochrome' and 'color'
> Printers support some extended color space modes, at least for raster 
> input, as advertised in the "urf-supported" attribute for Apple Raster, 
> and the "pwg-raster-document-type-supported" attribute for PWG Raster. 
> The extensions are:
>   - 16 bit per color instead of 8 bit per color in color or grayscale
>   - Adobe RGB instead of sRGB in color
> These extensions should be used depending on the input data from the 
> client and depending on the "print-content-optimize" setting for the job.
> Now I am looking into implementing this in cups-filters.
> To control the use of the extensions based on the input data we need to 
> find out the color depth of the input and also if it is perhaps Adobe 
> RGB instead of sRGB.
> For raster input data (Apple Raster or PWG Raster this info should be in 
> the raster header and we should simply take care to keep color space and 
> depth on any needed conversion, only exception is to convert to 
> grayscale or (dithered) bi-level if the user requests it via 
> print-color-mode attribute.
> As the client knows the printer attributes we expect that it only sends 
> raster data of (extended) color spaces which we support.
> More complicated is if for example CUPS receives a PDF job from a user 
> application, as here CUPS has to convert the PDF into the best possible 
> raster format for the printer. If the printer understands PDF, we pass 
> on the input PDF (only apply pdftopdf filter) and assume that the 
> printer to print it in the best possible quality.
> So being left with converting PDF to raster, here we would need to know 
> which color space and color depth the resulting raster data needs to 
> have so that the PDF's content is best reproduced but no unneeded 
> overhead is produced. To do so, we need to know of the color depth and 
> color space of the graphical elements of the PDF to get the maximum one 
> for each page (and naturally we should only produce raster which the 
> printer supports).
> So my question to the PDF experts here (Jay? Vikrant? Sahil?), how can I 
> determine from a page in a PDF file
> - which maximum color depth is needed to reproduce it?
> - is the PDF page sRGB or Adobe RGB?
> For raster-only PDFs (coming from a photo manager/editor or a scanner, 
> or PCLm) it is probably trivial, and one could make this working in 
> pclmtoraster.
> More complex it gets for actual raster graphics. Or does color depth in 
> the vector graphics of PDFs not exist and gets only introduced with 
> rasterization?
> And how relevant is actually Adobe RGB for printing? I assume that ALL 
> driverless IPP printers do sRGB and so if the input file is sRGB one 
> lets get it printed in sRGB.
> But for some reason some printers support printing Adobe RGB (and for 
> the JPEG output of EVERY digital camera you can choose between sRGB and 
> Adobe RGB). So if the input PDF is Adobe RGB we need to discover that 
> and take care that the raster is also Adobe RGB. I hope I am right.
> And how is all this influenced by the setting of "print-content-optimize"?
>     Till
> On 28/04/2021 13:43, Michael Sweet wrote:
>> Till,
>> With IPP you *don't* select color spaces as user options as those are 
>> artifacts of the file format and not part of the job ticket.
>> Realistically, the best thing to do is use the 
>> "print-content-optimize" value ('auto', 'graphic', 'photo', 'text', 
>> 'text-and-graphic') and/or the original document format (e.g. printing 
>> an image means default to photo mode, etc.) and then (if sending 
>> raster data) choosing an appropriate 
>> "pwg-raster-document-type-supported"/"urf-supported" value (which is 
>> where you will find the color spaces and bit depths that the printer 
>> supports). The current CUPS PPD generator uses these to generate 
>> ColorModel choices, which is how we let the user choose a color mode 
>> today.
>> In the future we should hide that implementation detail (maybe exposed 
>> under "expert controls"?) since it is confusing for a lot of users.  
>> Moreover, it is possible for a smart PDF RIP will detect the kind of 
>> colors being used in a PDF document and choose an appropriate raster 
>> color space and bit depth when rendering a page.
>> I know there are going to be people that scream, "I need to have 
>> absolute control over every aspect of my printing!"  But that kind of 
>> control doesn't belong in the printing system or in the main UI - it 
>> belongs in the Printer Application (or printer, in the case of an IPP 
>> Everywhere/AirPrint printer) because those are device 
>> process/calibration settings that are explicitly *not* part of the IPP 
>> model.  IPP has always been about specifying intent (*what* you want) 
>> and not process (*how* to do it).
>>> On Apr 28, 2021, at 4:17 AM, Till Kamppeter 
>>> <till.kamppeter at gmail.com> wrote:
>>> I have found one problem. For the color modes IPP has only the 
>>> following choices:
>>> "print-color-mode" = "Print Color Mode";
>>> "print-color-mode.auto" = "Automatic";
>>> "print-color-mode.auto-monochrome" = "Auto Monochrome";
>>> "print-color-mode.bi-level" = "Text";
>>> "print-color-mode.color" = "Color";
>>> "print-color-mode.highlight" = "Highlight";
>>> "print-color-mode.monochrome" = "Monochrome";
>>> "print-color-mode.process-bi-level" = "Process Text";
>>> "print-color-mode.process-monochrome" = "Process Monochrome";
>>> Apple Raster and PWG Raster support more modes though, especially 
>>> with 16 bit instead of 8 bit color depth, "device" color modes and 
>>> Adobe RGB instead of sRGB. Are there standard strings for these? And 
>>> where do I find them?
>>>    Till
>>> On 27/04/2021 20:02, Michael Sweet wrote:
>>>> Till,
>>>> The CUPS repository already contains a nearly-complete set of these, 
>>>> and they came from the IPP Registry project's exported strings from 
>>>> the IANA IPP registry.
>>>>      https://github.com/OpenPrinting/cups/tree/master/locale
>>>>      https://github.com/istopwg/ippregistry/tree/master/localizations
>>>> The PWG maintains a copy of the English strings (I've tried a few 
>>>> times to get localizations for other languages without much success) 
>>>> on their FTP server (also served by HTTP/HTTPS):
>>>>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.pot
>>>>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.strings
>>>>> On Apr 27, 2021, at 1:46 PM, Till Kamppeter 
>>>>> <till.kamppeter at gmail.com> wrote:
>>>>> Hi,
>>>>> while I was looking through the code of the PPD file generators in 
>>>>> CUPS and cups-filters for creating CUPS queues for driverless IPP 
>>>>> printers I wa thinking about where the human-readable strings for 
>>>>> the PPD files (and also for print dialogs) come from and whether 
>>>>> one could also generate PPD files translated into non-English 
>>>>> languages.
>>>>> I have also seen that printers supply human-readable strings for 
>>>>> options and choices via the URL listed in the printer-strings-uri 
>>>>> IPP attribute, but these strings are only for the options and 
>>>>> choices which are not IPP or PWG standard.
>>>>> Seeing this I thought that the wide majority of IPP attributes, 
>>>>> options, choices, and properties ar IPP/PWG standardized, and so 
>>>>> they should always be well served by the same human-readable 
>>>>> strings, independent of operating system, desktop, or other client 
>>>>> software being used.
>>>>> So it would be great to have some central repository for these 
>>>>> strings for any operating system and application software to use 
>>>>> when working with IPP printers. Is there something like that? Was 
>>>>> susch a thing already discussed at the PWG? Or is every OS or 
>>>>> application developer supposed to "invent" his own, personal set of 
>>>>> human-readable strings for standard IPP attributes?
>>>>>    Till
>>>>> _______________________________________________
>>>>> Printing-architecture mailing list
>>>>> Printing-architecture at lists.linux-foundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture 
>>>> ________________________
>>>> Michael Sweet
>> ________________________
>> Michael Sweet

More information about the Printing-architecture mailing list