[Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs

Michael Sweet msweet at msweet.org
Wed Apr 28 11:43:17 UTC 2021


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