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

[Rick Cochran]

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
>