[WIP] PPD option preset auto-generation for common job IPP attributes

[tillkamppeter]

To make the job IPP attributes "print-color-mode", "print-quality", and "print-content-optimize" actually doing "the right thing" for most printers we auto-generate PPD option presets now.

CUPS already had the functionality to apply a preset of one or more PPD option settings for each of the 6 combinations of "print-color-mode" and "print-quality" settings for longer time but this was never actually being made use of as it required manually defining the presets via "APPrinterPreset" PPD attributes. This no one wants to do with the ~10000 PPDs which come with a typical Linux distribution nowadays. Even a user with his few print queues does not want to do it, know how to do it, or know that it is even possible.

This way printing gets easier for users, as once they can print from simple print dialogs only offering stanard IPP options (and not the PPD option) like on phones or IoT devices, and second. they can print with the same standard options on any printer. With the lp command one can simply use a few options which work everywhere:

lp -d Printer -o print-color-mode=color -o print-quality=5 file.pdf
lp -d Printer -o print-color-mode=monochrome -o print-quality=3 file.pdf
lp -d Printer -o print-color-mode=color -o print-quality=5 -o print-content-optimize=photo file.pdf

This commit makes this fully automatic on every PPD where the presets are not already manually defined via "APPrinterPreset" attributes.

When creating the PPD cache for a queue's PPD file and the PPD is without manual presets, it calls the new function _ppdCacheAssignPresets() which analyses for each PPD option the names of the choices to find out which choices switch to manochrome or to color, lower or raise print quality, or improve text/graphics/photo printing and which are the moset suitable of them. It also analyses the PostScript/PJL code of the choices to find out whether it affects the printing resolution.

With this it selects which options get into the the presets and with which choices.

In addition to presets for the "print-color-mode"/"print-quality" combos presets for "print-content-optimize" are introduced.

PPD Option settings added by preset are logged on job execution.

[lgtm-com[bot]]

This pull request introduces 4 alerts when merging 3b07df3789490936567c5732179aad49cd2d3579 into e6be10920ca49e93beafdfa29a0e0e71d2d7d487 - view on LGTM.com

new alerts:

• 4 for Comparison result is always the same

[tillkamppeter]

The code does not build on Windows as Windows does not provide strcasestr(). I did not find a CUPS workaround or redefinition (like _cups_strcasecmp() for strcasecmp()). Is there some way to replace this function in CUPS?

[michaelrsweet]

@tillkamppeter We can add a strcasestr emulation function - we'll need it on a number of platforms other than Windows as well...

[tillkamppeter]

I have thought the same thing, already have added one, not yet committed, will do in the next 20 min or so.

[tillkamppeter]

I have converted the _cups_strcasestr() now. The implementation is very simple, probably does not work with huge strings, but for analysing option names it works very well.

And now the code builds under Windows!

[tillkamppeter]

This is all for all these existing PPD files dying a nicer death in the last 1 or 2 years on PPD-supporting CUPS 2.4.x ...

[zdohnal]

@tillkamppeter it looks there are some discrepancies in the PR which Mike mentioned and haven't been tackled yet, so I'll move it to 2.5 as it is a big bunch of new code.

[tillkamppeter]

OK, @zdohnal let us aim for 2.5.0 with it ...

[tillkamppeter]

Still really not happy with these changes. The added complexity and number of presets you will introduce for high-end printers will only cause problems for users and is not something that will be preserved in CUPS 3.0 anyways...

Some general feedback:

* You need to update the cache version number in ppd-private.h, otherwise existing cache files will not be regenerated.

I know, did it in the beginning but now I need to do it again ...

* The print-content-optimize enumerations still don't follow the registered keyword names.

OK, I will correct that.

Ultimately, what problem are you trying to solve with these changes?

The problem is the following:

If we have a CUPS queue with a PPD file, desktop print dialogs using libcups show all the options which the PPD provides, so the user can adjust them to the job's needs.

Now, if we share the printer CUPS makes it available via IPP, as a driverless IPP printer, like a Printer Application. Now there can be IPP clients which are not CUPS clients (mobile phones, Windows, ...). They show only standard IPP options in their print dialogs, especially the options print-color-mode and print-quality. For each of the 6i combinations of these 2 options the PPD cache has a preset option setting list and CUPS, when executing a print job, it applies the PPD options stored here for the selected combo of color mode and quality.

So my idea here was that if there are no manually created presets in the PPD file (APPrinterPreset) I try to fill these presets automatically with the most suitable settings from the PPD files, so that users with print dialogs limited to standard options can better make use of legacy printers where options for getting higher print quality or more speedy, economic printing or color/grayscale are not standardized.

The algorithm is based on existing PPD files, and in the age of CUPS drivers being replaced by Printer Applications, and PostScript printers being replaced by driverless IPP printers not many new PPD files will appear. So there will be not many new PPDs where the algorithm is missing options due to new names.

I created this already some time ago and deployed it in the PPD-retro-fitting Printer Applications and with this PR I thought to extend it to CUPS for the few years (now only months?) left until the switchover to CUPS 3.x (in Ubuntu I had applied it already as distro patch).