New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make PIN printing options from PPD available via Job Ticket API #4969

Open
michaelweghorn opened this Issue Feb 22, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@michaelweghorn
Copy link
Contributor

michaelweghorn commented Feb 22, 2017

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:

  • Ricoh-MPC5504-Postscript-deutsch-V1.2.ppd.txt: provides the option "JobLog" to enable/disable PIN printing and the 4 options "UserCode1", "UserCode2", "UserCode3", "UserCode4" to set the 4 digits of the PIN code
  • Canon-iRA_C7280_PS_deutsch.PPD.txt: provides the option "SecurePR" to enable/disable PIN Printing and the 4 options "SecuredPW4", "SecuredPW5", "SecuredPW6", "SecuredPW7" to set the 4 digits of the PIN code
  • cel-iradvc7280-pcl-en.ppd.txt: Uses an option "SecuredPassword"/"CustomSecuredPassword" to support a 7-digit PIN (This way of doing it is not supported by all print dialogs using the PPD API.)

(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

@michaelrsweet michaelrsweet self-assigned this Mar 8, 2017

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator

michaelrsweet commented Mar 8, 2017

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.

@michaelrsweet michaelrsweet added this to the Future milestone Mar 8, 2017

@michaelweghorn

This comment has been minimized.

Copy link
Contributor

michaelweghorn commented Mar 20, 2017

Thank you for looking at this and for the quick implementation of mapping for other keywords (handled in separate issues).

I have now created a bug for foomatic: https://bugs.linuxfoundation.org/show_bug.cgi?id=1393

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.

Despite the opposite order in the PPD file, "SecuredPW4" is the first digit to be entered at the device, "SecuredPW5" is the second one, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment