[cups] PPD API: Status, future and alternatives to handle printer-specific options
msweet at apple.com
Tue Feb 7 14:48:17 PST 2017
Thanks for the bug reports!
More responses inline below...
> On Feb 7, 2017, at 5:34 PM, Michael Weghorn <m.weghorn at posteo.de> wrote:
>>> * The option for "confidential printing" (printer only prints when the
>>> PIN given in the print dialog is entered on the device) is only avaible
>>> via the PPD API (options "LockedPrintPassword", "UserCode1",
>>> "Usercode3", "UserCode3", "UserCode4").
>> PPD-based PIN printing like this is not compatible with CUPS or IPP and only works for PostScript printing.
> "Confidential printing" is one of the functionalities very widely used
> in our organization. Not supporting it at all any more is not an option
> for us, as it breaks use cases and I am pretty sure this will not be
> (Printers can e.g. be located in a room on one floor of a building which
> is accessible to a lot of people. People send their print jobs and want
> the actual printing to only take place when they are next to the
> printer, to make sure nobody else fetches the printout.)
> As far as I understand, the "job-password" IPP attribute (which you
> mentioned in an earlier email) is similar in functionality, but our
> devices currently do not support it (when querying their attributes
> using "ipptool", neither this nor something similar is included in the
> Our preferred solution would be the proper option being used/supported
> by the device, but that is something where we depend on the vendor to
> take action and provide firmware that supports this (s.a. below) and I
> am not sure this will be possible in the near future.
> Would there be any other way to support this functionality?
Unfortunately, PPD-based PIN printing is implemented in a LOT of different (and incompatible) ways. Some vendors use a single option with multiple choices, others (like this Ricoh PPD) implement a separate choice for each digit *plus* an option to enable it.
On top of that, PIN printing like this only works when printing PostScript...
If you can collect sample PPDs that offer PIN printing options, please file a bug for it and attach the PPDs. *If* we can support it without too much trouble I will consider adding support to help folks until vendors like this implement proper support through IPP...
> Would using another keyword (or multiple keywords) help ins some way?
No, it would just make the problem worse.
> The CUPS-specific PPD extension "cupsJobPassword" (as described at )
> seems to be providing very much the same functionality.
> (I don't know whether that can in any way be used to make the feature
> work, map it to an IPP attribute and cause the required PostScript code
> being inserted into the print document...).
"cupsJobPassword" just enables UI for the IPP job-password attribute.
>> This is largely due to this PPD using vendor keywords instead of standard ones. (cupstestppd is useful for alerting you to some of these issues).
> When I run "cupstestppd" on the PPD file, I only get warnings of the kind
> Size "<size>" sould be <other_size_spec>".
> When I run in verbose mode (Option "-v"), it just displays "PASS
> <option_name>" for all options, e.g. also for "DefaultUserCode1".
Yes, it won't warn about arbitrary vendor options, but it should warn about non-standard usage of standard options (i.e. it should be warning about "Booklet" not being a boolean option).
> Despite all the drawbacks in the use of PPDs and vendor-specific options
> therein, they mostly "just work" right now when using the PPD API
> because all options in the PPD are always available via the PPD API and
> can thus be selected in the print dialog.
Actually, PPDs provide LESS functionality than the corresponding IPP attributes, especially WRT finishers.
> Furthermore, Till mentioned plans for a Common Print Dialog (CPD) 
> and the further discussion of it is also relevant as it might
> potentially make Qt-specific changes in printer option handling unnecessary.
Unfortunately, CPD has been in the wings for many years now but has no developers/resources for it. Unless that situation changes you'll need to focus on a "native" Qt solution.
Michael Sweet, Senior Printing System Engineer
More information about the cups