[cups] PPD API: Status, future and alternatives to handle printer-specific options

[Michael Sweet]

Michael,

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
> accepted.
> (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
> output).
> 
> 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 [1])
> 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) [2]
> 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