Adding support for the Common Print Dialog Backends (CPDB)

[Till Kamppeter]

On 27/03/2024 08:34, Michael Weghorn wrote:
> 
> Thanks for the detailed description. Since printing is a critical feature for 
> many users and the current CUPS/PPD API implementation has been used 
> successfully for quite a long time now, I wouldn't feel comfortable 
> unconditionally replacing it with the CPDB-based approach at this point in time. 
> (So I'm glad that isn't the goal for the GSoc project.)
> 
> Of course, switching the default to the CPDB-based implementation and ultimately 
> dropping the custom CUPS/PPD API implementation are things that can be 
> considered at some point in the future, once the CPDB-based implementation has 
> proven to be able to cover all relevant use cases and all relevant distros 
> provide the libraries and printer applications,....
> 
> (I remember that the CUPS PPD API has been deprecated for a long time, and the 
> IPP-based API would have provided the necessary means to make everything work in 
> theory. But at least in pre-printer-application times, the practical problem I 
> saw years ago was that - even then new - printers weren't offering all of their 
> functionality as IPP attributes, so still using the deprecated API was the only 
> way to not lose that functionality. IIUC, printer applications are meant to 
> bridge that gap now.)
> 
> 

Michael, Biswadeep will take care of the CPDB interface, but the CUPS/PPD 
interface also needs attention, as if it is not done correctly, it will cease to 
work if CUPS 3.x is used (also if the CUPS Snap or any other containerized form 
of CUPS is used).

So the CUPS interface (I intentionally do not call it CUPS/PPD interface) 
following has to be assured:

1. The correct CUPS APIs have to be used (cupsEnumDests(), ...), to list both 
classic, permanent CUPS queues with PPD file and IPP print destinations for 
which CUPS creates a queue on-demand. The GTK print dialog (GTK version 4.x) 
uses these APIs, to have an example.

2. Also for obtaining the options only these new "Dests" APIs of CUPS have to be 
used, no old PPD-downloading APIs, and especially no direct access to PPD files. 
The "Dests" APIs for options automatically take care what the best is for 
obtaining the options (including providing all PPD options if the queue is a 
classic CUPS queue), and they continue to be available in libcups3. Take the GTK 
(4.x) print dialog as example for use of these APIs.

3. Generally take care to use only libcups API functions which are also 
available in libcups3. Also make the code build with both libcups2 and libcups3 
(see the projects libcupsfilters (2.x) and libpappl (1.4.x branch) as example 
repos which can be compiled with the user's choice of libcups2 or libcups3.

Biswadeep, please concentrate primarily on the CPDB interface. If you finish 
early, you can also work on the CUPS interface, but the CPDB interface is your 
priority.

> Thanks! I've followed those instructions, am happy to co-mentor.

Thank you very much.

You are now officially registered as mentor and you can see the submitted 
proposals now. Please mark at Biswadeep's proposal that you are interested in 
mentoring. Also have a look into Biswadeep's proposal itself.

You will do the LibreOffice side of the mentoring, Gaurav Guleria and me will do 
the CPDB side.

    Till