michaelrsweet
commented
7 years ago OK, each of these PPDs do things a bit differently, and it isn't clear what the order of digits actually is for the second PPD.
Another problem with these PPDs is that they rely on foomatic, which does some very strange things with the options themselves (which means we'd need to do other nonsense just to get foomatic to understand things... :/)
Right now I'm going to keep this open but in the "Future" milestone. In the meantime, please open up a bug against Foomatic to add support for the cupsJobPassword keyword in PPDs - then we can rely on using the "job-password" attribute/option and have the driver (Foomatic) convert as needed for the printers.
michaelweghorn
As recently discussed in the thread "PPD API: Status, future and alternatives to handle printer-specific options" on the CUPS mailing list [1], [2], CUPS currently does not match PPD keywords for PIN printing to anything that is available via the Job Ticket API as well.
PIN printing (also sometimes called "confidential printing" or "secure printing") is a functionality mostly used in enterprise environments. The user chooses a PIN for a print job and the printer only starts printing when the user inserts the same PIN at the device. (So no other person can fetch the printout while the user is on the way from his/her room to the printer in a central location.)
As devices whose PPD files offer that functionality do not necessarily also support a respective IPP option by themselves (which could make using the PPD file unnecessary in favour of querying options via IPP), this is a potential issue when migrating print dialogs from the deprecated PPD API to the Job Ticket API.
As suggested on the CUPS mailing list [3], I am therefore asking to add support for this and map the PPD option to a respective IPP attribute (possibly "job-password"?).
Unfortunately, different vendors and different PPDs have different ways of specifying the options for PIN Printing. Sample PPDs of some printers providing that functionality are attached:
(There is probably a multitude of other ways how this is currently done by different vendors...)
If this makes it easier to support mapping the respective PPD options to IPP attribute(s), I would find it acceptable to require that specific keywords are used in the PPD file for the PIN printing (e.g. to require the administrator to change the name of the options of the first two PPD files to match those supported by CUPS).
PS: The first two PPDs are ones used in our organization, the third one is one from the vendor's website. The second and third PPD are basically two different PPDs for the same printer model.
[1] http://lists.cups.org/pipermail/cups/2017-January/thread.html [2] http://lists.cups.org/pipermail/cups/2017-February/thread.html [3] http://lists.cups.org/pipermail/cups/2017-February/028211.html