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
