On 2024-03-26 18:26, Till Kamppeter wrote:
This is no problem to keep it optional, so that the packager/admin/user can choose, at least at build time, perhaps even at run time.
Great.
But note that PPD files and classic CUPS drivers are deprecated. CUPS 3.x, getting completeky released near the end of this year will not support PPD files and addable driver filters any more, but exclusively support driverless IPP printers. For legacy (non-driverless) we have introduced the concept of Printer Applications, software emulations of driverless IPP printers.This requires changes on the print dialog:- List IPP print destinations, independent whether there is a CUPS queue for them or not (if not, CUPS would create a temporary queue) - Obtain printer capabilities and options via IPP, do not try to download the PPD file via CUPS or even try to directly access it in the file system.This can be principally obtained by using the current CUPS APIs (the "Dest" ones, already available in libcups2 for several years). Also all PPD-related APIs will go away in libcups3.The CPDB backend for CUPS is already completely updated to the new CUPS 3.x realm and can actually be built with libcups3. This means with a CPDB-supporting print dialog we can smoothly transition from CUPS 2.x to CUPS 3.x without loss of functionality and without loss of access to any of the available print destinations.Also the CPDB backend for CUPS is maintained by OpenPrinting, the maintainer of CUPS and is updated along with any future change on CUPS. So CPDB-supporting print dialogs will keep working in case of such a change, so the maintainers of the print dialogs do not have to keep pace with that.So the CPDB option for the LibreOffice dialog will work with CUPS 3.x and future versions, the CUPS/PPD option requires updating by the maintainers of the LibreOffice dialog.
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.)
So I am inviting you as GSoC mentor officially. To get access to all resources I do an invitation to the GSoC dashboard. Please watch out for an e-mail from Google and follow the instructions in it. If you do not feel comfortable to use these facilities, please tell me and I will do the official part.
Thanks! I've followed those instructions, am happy to co-mentor.
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
