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

[Michael Weghorn]

Hi Michael,

thanks for your reply which helps me a lot in better understanding
various aspects.

> Most of the stapling options in this PPD are non-standard keywords.  But please feel free to file a bug requesting that we support them.

This is https://github.com/apple/cups/issues/4960.

> Booklet in the PPD spec is a boolean option, so this PPD violates the 4.3 spec (the last one published). In this case the only values IPP would support (and so the only ones we will support in CUPS) are "None" and "OpenToLeft".
> 

That sounds reasonable.

> Please file bugs requesting support for RIPunch and RIFoldType.

I did; those are: https://github.com/apple/cups/issues/4961 and
https://github.com/apple/cups/issues/4962

>> * 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?

Would using another keyword (or multiple keywords) help ins some way?

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...).


> 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".


> Please provide examples of what you feel is important but missing.  I want to stress that pretty much all printers (aside from some industrial label printers) made in the last 7 years support IPP/2.0 and the full functionality of the printer through IPP.  (note: some older printers might require firmware updates)
> 
> That includes the printer you are testing with, BTW, so no need to use a PPD at all...

Examples for what I considered to be missing at first glance include
those options I mentioned in my previous email like more options for
stapling, support for punching and folding, for which I have now opened
bugs as you suggested. (So support for those options will possibly be
implemented at least for the given sample PPD file.)

As mentioned above, an important functionality for us is "confidential
printing" which is currently not supported via IPP on our devices. I did
not get over all other options so far, but should probably do so.

We would like to be able to use that printer (and others) without a PPD
for another reason as well as one big drawback we have with the current
PPD is that the print files are always converted to PostScript first
(while most applications generate PDF files for printing). When we asked
the vendor some time ago (maybe 1-2 years), we were given the answer
that there was no way to use both, PDF as print format and have the
support for all printer-specific options via IPP or by other means (for
the device in use then, which was another model).

We made a similar request in December last year (when new models were
delivered) and are currently awaiting a response.

> 
> We can support all printer features through IPP.  That does not necessarily mean we will support all PPD options (which often expose driver or PostScript "features"), but that is a good thing - too many vendors have made really bad decisions about driver UI/options which don't work well and/or are confusing to users.

In general, I agree that the current situation with PPD options etc. is
unfortunate and many of the drawbacks will probably be addressed by the
migration to IPP/IPP Everywhere and driverless printing.

One point I worry about is that it depends pretty much on the devices
supporting relevant IPP attributes (or all relevant PPD options being
mapped to IPP attributes by CUPS) for the switch to the new API to work
well without losing much functionality.

Hopefully, this will be mostly supported "out of the box" for all new
devices, but there are a lot of older devices around in our organization
(from small printers to plotters to particular special devices, many of
which I have never seen or even heard of...).

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.

Some of those PPD options might be what you mean when you talk about
"esoteric vendor-specific PPD options for obsolete printers".
I agree that having those is unfortunate, but think it is very likely
that there are use cases (most of which I don't even know of yet) that
will possibly break when those are simply no more available as they are
not mapped to any equivalent IPP attributes. Right now, I can just
speculate as I don't know more exactly what kind of options might be
affected in detail...
(But there were already several ones that were not mapped "out of the
box" with a pretty new device.)


Taking a step forward always has the potential to break other things, so
this is something we probably need to try out and deal with at some
point in time.

I think that there are some things that need a closer look before taking
a decision what exact direction to take right now (e.g. more
experimenting; having a closer look at some more printers currently in
use within our organisation).

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.


    Michael

[1] https://www.cups.org/doc/spec-ppd.html#cupsJobPassword
[2]
http://lists.qt-project.org/pipermail/development/2017-February/028654.html