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

Tue Jan 31 10:51:22 PST 2017

Rick,

A Mac has never been able to do this.  We may guess at a compatible driver, but realistically aside from generic PostScript and PCL most drivers simply don't work with Windows.  And many vendors simply don't care to support this kind of compatibility between their Mac and Windows drivers.

> On Jan 31, 2017, at 12:43 PM, Rick Cochran <rcc2 at cornell.edu> wrote:
> 
> Michael,
> 
> To be specific:
> 
> How will a Mac be able to obtain a proper driver for a queue on a Windows print server?
> 
> Thanks,
> -Rick
> 
> 
> On 1/31/17 11:58 AM, Michael Sweet wrote:
>> 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
>> 
>> _______________________________________________ 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