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

[Michael Sweet]

Till,

> On May 15, 2017, at 10:34 PM, Till Kamppeter <till.kamppeter at gmail.com> wrote:
>> ...
>> 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?

The lpoptions file.

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

Not going to happen since they would need to expose the fact that there are PPDs.

>> 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()?

Yes, and its implementation depends on cupsSetDests.

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

PPDs are only needed for CUPS printer drivers/filters, which are a legacy artifact of old printers that do not implement current standards.

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

I suspect you could replace or remove the PPD for a temporary queue in the current implementation, but that is an artifact, not the intended semantics, and could change in future implementations.

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

Even back in the days of CUPS browsing we created local (raw) queues that pointed to the server to handle the dequeuing.

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

Sigh...  If you just use the published CUPS APIs you get 1 and 2 automatically!

_________________________________________________________
Michael Sweet, Senior Printing System Engineer