[cups-devel] Printer Setup Tools and deprecated PPD API

[Till Kamppeter]

Thank you for the answers.

On 05/15/2017 08:55 PM, Michael Sweet wrote:
>
> Printer setup/management tools should continue using the CUPS-Add-Modify-Printer operation and PPD files, as that is the supported mechanism for creating long-lived or shared print queues.  Ordinary applications, however, should stay out of the printer driver and queue creation business and use the documented APIs for enumerating printers and submitting jobs.
>

OK.

>> But how do I set the default option settings of a print queue, for example the default paper size, default print quality, or generally, after I have got a list of options, choices, and default settings of an existing print queue using the new CUPS API, how do I change the defaults, either with CUPS API functions or IPP calls?
>
> cupsSetDests can still be used to save default options, even for short-lived "local" queues.  The default media size comes from the printer/queue, so legacy PPD-based queues get the system-wide default (letter/a4) while (temporary) IPP Everywhere queues get it from the printer itself.
>

When I use cupsSetDests for system-wide defaults, does it modify the 
queue's PPD file or does it modify /etc/cups/lpoptions?


>> To find out this I have looked into the code of the printer setup tools which come with CUPS: lpadmin and the admin part of the web interface. Both make use of the deprecated PPD interface and do something rather awkward: They download the printer's PPD, edit the "*Default..." lines to represent the changed default settings and do an add-modify-printer IPP call with the new PPD file so that the file gets uploaded into the CUPS queue.
>
> Correct, when setting the PPD (network-wide) defaults, those tools edit the *Default lines in the PPD.
>

Would be great to have CUPS APIs for that. Then these APIs could be also 
used wen in the future there are no PPDs any more.

> The lpoptions command edits the local (system or per-user) defaults which are stored separate from the PPD file.
>

So this command is the command-line-equivalent of cupsSetDests()?

> For PPD-based print queues, this is the way it is.  Which is one of the reasons why (re)creating queues automatically in cups-browsed does not scale.
>

OK.

> lpoptions (what you save with cupsSetDests) can survive queue removal.

This I did not know before. Then cupsSetDests() would be a good solution 
for saving option settings for queues pointing to remote CUPS queues, 
which are not shared anyway.

 > If you want to have a more permanent cache of options than what CUPS 
supplies then you'll need to create your own.

This is what cups-browsed is currently doing.

>
>> Also there is no way to create non-raw CUPS queues except queues with auto-created driverless PPD or queues where one supplies a PPD.
>
> ... or specifies an installed PPD with the "ppd-name" attribute.
>

OK.

>> Or is the deprecation of the PPD API for now only intended for clients who do not more than printing, and not for printer setup tools?
>
> At the moment you still need to use the PPD API (or at least deal with PPDs) when creating legacy print queues. That is an implementation detail in CUPS that is present solely to support printer drivers, so management/setup tools that support creating or modifying queues with printer drivers still need to deal with PPDs.
>

So then it is OK to create print queues with PPDs and have the filters 
read from PPDs. So I would need the PPD API be conserved, for the 
filters. Or it will move over into cups-filters when it is taken out of 
CUPS.

> However, since CUPS 1.4 (~8 years) we have been pushing for user applications to move away from using the PPD API and instead using the IPP (Everywhere) printer options and APIs.  These work for all types of queues (including raw queues) so that clients do not need to depend on hacks like cups-browsed.
>

Only the manufacturers only made printers using drivers 8 years ago and 
so one had to create print queues with a PPD file.

The print dialog backends developed in this year's GSoC will not use the 
PPD API. The CUPS backend will strictly follow the new CUPS Programmer's 
manual, the IPP backend will look up printers and remote CUPS queues via 
DNS-SD and create temporary CUPS queues when the user selects a printer 
to print on.

>> I have the following questions:
>>
>> 1. If I want to change the default option settings of an existing print queue, can I do this without downloading the PPD and editing it?
>
> If you want to change them network-wide, no.  If you want to do it for the system or current user, the cupsSetDests function works just fine.
>

OK. See above.

>> 2. If I want to create a filtered (not raw) queue, can I do it without supplying a PPD, but instead, somehow by supplying the options, capabilities, destination file format, ...?
>
> If you have an IPP Everywhere-compatible printer, you can use the CUPS-Create-Local-Printer operation (which only works when talking to the local cupsd - not compatible with remote admin) followed by a CUPS-Add-Modify-Printer operation to set the "printer-is-shared" attribute to 'true'.
>
> Otherwise, a permanent print queue that does filtering requires a PPD file, as an implementation detail of CUPS.
>

OK. First operation creates PPD automatically. So filtered queues always 
have a PPD.

>> 3. I know that I can create local (temporary) print queues with PPD auto-generation for driverless IPP printers, can I also create a temporary queue with a PPD supplied by me or a temporary raw queue?
>
> No.
>

OK, so temporary queues are only for creation by the print dialog to 
print on a DNS-SD-discovered driverless IPP printer or a remote CUPS queue.

>> 4. If I create a temporary CUPS queue for driverless printing using the URI of a remote CUPS queue, what will happen? Will the remote CUPS queue be considered an IPP Everywhere printer and so the local, temporary queue gets an auto-generated PPD or will the remote CUPS queue be recognized as such and so the local, temporary queue will be created as raw queue?
>
> The CUPS-Create-Local-Printer operation only creates an IPP Everywhere queue.  So a remote CUPS server (which looks like an IPP Everywhere printer) will get its own auto-generated PPD and the client will end up sending it a PDF (or JPEG) file along with standard IPP options.
>

OK, no problem, so printing on remote CUPS queues using the IPP backend 
for the print dialog will also work this way.

>> 5. Can I create, by an IPP call, a permanent queue where CUPS auto-generates a PPD for driverless IPP printing?
>
> No.
>

OK, will probably not be necessary, and a workaround to get one any way 
would be share and immediately afterwards unshare.

>> 6. Can I make a temporary queue permanent without sharing it?
>
> No.
>

OK.

>> 7. If I have a temporary queue and share it, it gets permanent, what happens if I remove the shared bit, does it continue permanent or does it return to temporary?
>
> It continues to be permanent.
>

Would be a workaround to get a permanent queue with auto-generated PPD, 
but probably not actually needed.

>> 8. What happens if I change the device URI of a temporary queue? Does the PPD stay the original, driverless PPD? Does the queue stay temporary? Or does it turn permanent?
>
> The PPD stays unchanged, and the queue remains temporary.
>

OK.

>> 9. Which operations in general make a temporary CUPS queue permanent?
>
> CUPS-Add-Modify-Printer with "printer-is-shared" = 'true' will make a queue permanent.
>

OK, so one can do everything what one can do with a permanent queue 
except sharing and the queue stays temporary. Is it even possible to 
replace or remove the PPD file and the queue stays temporary (I do not 
know whether this would actually make sense in real live)?

>> Which operations make a permanent queue temporary?
>
> There are none - once permanent, the only way to get rid of the queue is with CUPS-Delete-Printer.
>

OK.

>> 10. It is possible to have a class where the members are remote CUPS queues? Or do they have to be CUPS queues on the local machine?
>
> They must be local queues.
>

OK. Had been nice for creating load-balancing queues.


This is all about the future of the printing architecture under Linux 
and similar operating systems.


My plans are to let all print dialogs (GTK, Qt, LibreOffice) share 
backends which do the actual access to the printing system, new backends 
being added if new print services or technologies appear.

The backends planned for now (and under development in the GSoC) are:

1. CUPS backend - Uses CUPS APIs of new CUPS Programmers Manual, no PPD 
API. Lists the (permanent-only?) CUPS queues of the local CUPS daemon.

2. IPP backend - Lists printers discovered by DNS-SD, IPP network 
printers, IPP-over-USB printers, and remote CUPS queues, when the user 
selects one to print on, a temporary CUPS queue is created so that 
options can be displayed and the job be sent.

3. Google Cloud Print backend - Lists the GCP printers of the user who 
is currently logged in. Does not use CUPS, as CUPS queues are always 
system-wide and GCP printers are the user's personal resource.

In small home networks and on mobile devices cups-browsed is not 
actually needed any more, as the IPP backend replaces it in this simple 
case of not needing load-balancing printer clusters and remote CUPS 
servers being CUPS 1.6.x or newer.

cups-browsed will be continued, to provide additional functionality, 
especially interoperability of CUPS 1.5.x or older with CUPS 1.6.x or 
newer, to create load-balancing printer clusters, and to allow complex 
filtering on which remote queues/printers one wants to see and which not.

Before, cups-browsed was emulating the functionality of temporary CUPS 
queues, before CUPS 2.2.x came up, mainly to get easy access to remote 
CUPS queues which simply pop up like under the old CUPS 1.5.x with CUPS 
browsing. Queues are temporary as cups-browsed removes them on shutdown. 
It also replaced and still replaces the load-balancing queue clusters of 
former CUPS.

Currently cups-browsed has to do its job as long as the new print dialog 
work of the GSoC is not yet adopted, as current print dialogs are simply 
only listing CUPS queues of the local CUPS daemon, no DNS-SD discovery 
with temporary queue creation.

Development plans on cups-browsed are making use of temporary CUPS 
queues and using temporary CUPS queues and cupsSetDests() eliminate the 
need of creating and manipulating PPDs.

    Till