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

[Michael Sweet]

Rick,

As is apparent from how CUPS is currently supporting IPP Everywhere, it is entirely possible and feasible to map IPP to PPDs and vice-versa, so it will be possible to support legacy environments and applications with synthesized PPDs in the eventual future where CUPS does not depend on PPDs to prepare documents for printing...


> On Jan 31, 2017, at 10:03 AM, Rick Cochran <rcc2 at cornell.edu> wrote:
> 
> The great thing about standards is that there are so many of them.
> 
> I don't see how those of us in a mixed OS environment will be well served by the end of PPDs. It looks like both Apple and Microsoft are saying, "That's your problem, not ours."
> 
> This is not meant to disparage the wisdom and good work of Michael Sweet.
> 
> Yours,
> -Rick
> 
> 
> On 1/31/17 9:19 AM, Michael Sweet wrote:
>> Michael,
>> 
>>> On Jan 31, 2017, at 3:21 AM, Michael Weghorn <m.weghorn at posteo.de> wrote:
>>> 
>>> Hi,
>>> 
>>> CUPS' PPD API has been deprecated for quite a while now.
>>> 
>>> On the other hand, it seems to me like it was still used in many places.
>>> 
>>> As far as I understand it so far, the use of IPP (and in particular IPP
>>> Everywhere) makes the direct use of PPDs unnecessary.
>> 
>> Correct.
>> 
>>> I do not yet have a deeper understanding at everything currently happening
>>> in the are of IPP Everywhere and driverless printing, but I followed the
>>> discussions a bit and it sounded to me like PPDs were still used in
>>> conjunction with them and are generated in the background by CUPS (and/or
>>> cups-browsed) and are still used internally.
>> 
>> Currently, yes.  But that is just an implementation detail and not a
>> permanent state of affairs...
>> 
>>> Most print dialog implementations I know of rely on the use of PPDs (and
>>> the PPD API) in order to provide printer-specific options and pass them to
>>> CUPS.
>> 
>> That is unfortunately true at present.
>> 
>>> The documentation of the PPD API explicitly says: "The PPD API is
>>> deprecated starting in CUPS 1.6/macOS 10.8. Please use the new Job Ticket
>>> APIs in the CUPS API documentation. These functions will be removed in a
>>> future release of CUPS." [1] When I looked at that a while ago, I did not
>>> find out how to process all printer-specific options (like input trays,
>>> stapling, colour mode, confidential printing with PIN, etc.) using the Job
>>> Ticket API rather than the deprecated PPD API.
>> 
>> The <cups/cups.h> header contains (convenience) definitions for all of these
>> except "confidential printing with PIN" which doesn't have a direct mapping -
>> generally speaking *some* printers will support the "job-password" attribute
>> which provides questionable confidentiality along with "job-sheets" which
>> allows you to label the job as "confidential", "secret", etc.
>> 
>>> I would be very grateful if somebody could give me more information on the
>>> following questions:
>>> 
>>> 1) Is my understanding as described above basically correct? (Corrections
>>> and additional information are welcome.)
>> 
>> Yes.
>> 
>>> 2) What is the recommended way to handle printer-specific options in a
>>> print dialog? Which API should be used? (The implementation should support
>>> both "traditional" printers set up via PPD files and PPD-less printers like
>>> IPP Everywhere printers.)
>> 
>> Use the new API.  CUPS maps old PPD options to IPP/IPP Everywhere options.
>> 
>>> 3) Are there concrete plans regarding the removal of CUPS' PPD API? Is it
>>> possible to roughly say when it is probably going to disappear?
>> 
>> It is not likely to be removed in the near future.  But given that 98%+ of
>> the printers sold since 2010 work with CUPS' IPP Everywhere support, you can
>> expect that within a few years PPD support will be completely unnecessary.
>> 
>>> Background: The Qt 4 print dialog handled printer-specific options using
>>> the PPD API but the implementation had been rather broken in Qt 4 and was
>>> removed for Qt 5, with the plan to reimplement them as part of a new
>>> printing system. However, work on the new printing system could not be
>>> continued due to lack of time and money. Currently, printer-specific
>>> options are not available in the Qt 5 print dialog (apart from duplex and
>>> color mode). We are currently considering to implement support for
>>> printer-specific options in Qt 5 and would like to do it "right", i.e.
>>> avoiding deprecated APIs and doing it in a way that is supported in the
>>> future as well. (More information on the discussion for the Qt print dialog
>>> can be found on Qt's mailing lists. [2], [3], [4])
>> 
>> Use the new APIs.
>> 
>> _________________________________________________________ Michael Sweet,
>> Senior Printing System Engineer
>> 
>> _______________________________________________ cups mailing list
>> cups at cups.org https://lists.cups.org/mailman/listinfo/cups
>> 
> _______________________________________________
> cups mailing list
> cups at cups.org
> https://lists.cups.org/mailman/listinfo/cups

_________________________________________________________
Michael Sweet, Senior Printing System Engineer