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


Reply via email to