Inconsistent behavior of `print-quality` IPP attributes
CUPS queues are IPP printers, reporting the print-quality attributes in their printer attributes, with choices draft, normal, and high:
$ ipptool -tv https://localhost:631/printers/QUEUE get-printer-attributes.test
[...]
print-quality-default (enum) = normal
print-quality-supported (1setOf enum) = draft,normal,high
[...]
but when one prints to a CUPS queue or sets its defaults only the choices 3, 4, and 5 are accepted, especially
lpadmin -p QUEUE -o print-quality-default=high
produces in /etc/cups/printers.conf (only visible after stopping the CUPS daemon, but internally used immediately)
Option print-quality 0
which is an invalid value leading to all jobs to this queue not being printed (at least if they are not supplied with a valid print-quality option setting).
I have discovered this when updating and testing the CUPS Snap. It includes cups-browsed to make printers available to out-of-date print dialogs. (Driverless) Printers were correctly discovered and listed in the dialogs but printing on them did not work at all. cups-browsed saves option defaults and restores them using the IPP equivalent of lpadmin -p QUEUE -o OPTION-default=CHOICE and saved also print-quality, leading to the above-mentioned problem.
-
Here consistency is needed, CUPS accepting
draft,normal, andhighforprint-quality. For backward compatibility3,4, and5can also be accepted. -
If CUPS receives an unsupported setting for an option or attribute it has to use the valid default, not another unsupported value.
"print-quality" is an enum (number) attribute, so "draft", "normal", and "high" are not acceptable values.
Conceptually cupsEncodeOption could see the enum type in the attribute list and use ippEnumValue to convert from string to enum value.
But if IPP reports as a printer attribute
XXX-supported (1setOf enum) = AAA,BBB,CCC
I either need to be able to send a job with XXX=AAA to CUPS or somehow know which number I have to use for AAA.
How will it work then?
And also, if normal is not a valid value, CUPS should not assign another invalid value (0) but ideally do not change anything, or at least set the (valid) default value.
Till, if you are referring to the ipptool text output, it uses ippAttributeString which uses ippEnumString to convert integer enum values to their keyword equivalents.
WRT cupsd enforcing supported values, that is a valid complaint and it something we should be able to do, at least for the standard IPP attributes.
[master 1ee7183bc] Support enum keywords (Issue #734)