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

Michael Sweet msweet at apple.com
Sun Feb 5 19:32:26 PST 2017


Sorry for the delay in responding.  My answers are inline below, but the short answer is: please don't focus on esoteric vendor-specific PPD options for obsolete printers.  We are happy to improve the mapping of PPD options to IPP, but not at the expense of supporting modern printers.

> On Feb 2, 2017, at 11:03 AM, Michael Weghorn <m.weghorn at posteo.de> wrote:
> ...
> Many PPD options were nicely mapped to respective IPP attributes.
> However - as far as I can see - there is also quite an amount of options
> that only seem to be available via the PPD API, e.g.
> * The PPD has more detailed options for stapling (where to staple) while
> (as far as I can see), stapling is only represented by the enum value 4
> for the "finishings" attribute when using the new API (as far as I
> understand from a quick look at RFC 2911).

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.

> * Options for punching ("RIPunch"), folding ("RIFoldType"), booklet
> ("Booklet") and many other more specific options seem to be available
> only via the PPD API. This might be because vendor-specific keywords are
> used in the PPD.

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

Please file bugs requesting support for RIPunch and RIFoldType.

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

> As the arrangement of PPD options and their IPP counterparts are
> different (e.g. the separate "Stapling" option in the PPD seems to be
> mapped to an enum value "4" underneath the "finishings" option in IPP),
> I might have missed something, but my current impression is that using
> the new API actually leads to a loss in functionality as compared to
> using the PPD API.

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

> While I would prefer avoiding the PPD API, there are important and valid
> use cases based on options that are currently available when using the
> PPD API but of which I currently don't know how they could be supported
> by only using non-deprecated API functions.

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

> ...
> Is there a way to support more options using the new API?

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.

> I looked a bit at the IPP specifications. Section 6 of RFC 2911 seems to

Note that RFC 2911 was recently replaced by RFC 8011 (and 2910 by 8010) in preparation for moving IPP/1.1 to full Internet Standard.

> allow vendor-specific extensions for IPP attributes etc. Would that
> possibly be a way to map more PPD options to IPP and make them available
> without using the PPD API?

Realistically this is not necessary.  For example, the only options in your test PPD that are not handled by IPP already are watermarking and output orientation (which are printing system/graphics pipeline things), and PostScript color management options (which has long been superseded by ICC).

> I also think that there will be new devices in the future that will
> provide features not (yet) covered by standardized IPP attributes. (How)
> Will those features be supported by CUPS?

The same way any other new features will be handled - by updates to IPP (through the Printer Working Group, whose membership includes all of the major printer vendors) and (as needed) updates to CUPS.

For example, over the last 3 years the PWG has updated support for finishers (staples, folders, etc.) twice - first in IPP Finishings 2.0 which was a major update that allows clients to preview and specify the results of finishing processes, and now in IPP Finishings 2.1 which adds new finishing templates (the traditional enum/keyword approach in IPP) and fine-grained controls.  Both of these specifications push the limits of what is possible/supportable by printers today and both far exceed what is possible in PPDs.  But at the same time clients can discover the new capabilities through the existing IPP interface - very little has to change to support new finishers (and CUPS fully supports IPP finishings...)

At the same time IPP abstracts away options that the printer can determine based on the print intent (quality/resolution/content-type/etc.) - there is no need for the user to know what dithering algorithm needs to be used for a particular kind of document, or how many bits per pixel are best, etc.

> In issue #4952 you wrote [2]:
>> So while we definitely want to ensure that we expose all of the print
> qualities supported by the printer, we have no interest in separately
> exposing all of the printer resolutions that are supported.
> Does this mean that it is generally planned to support all options
> already available in a PPD file. Is this already the case and I have
> possibly just missed something?

We will support the core printer features, but not PostScript-specific or driver-specific options.

Instead of comparing the PPD options to the new CUPS IPP options, compare the CUPS IPP options to the options directly supported by the printer.

Michael Sweet, Senior Printing System Engineer

More information about the cups mailing list