On 2024-03-27 15:26, Till Kamppeter wrote:
Also, if we would clean up and update the current CUPS/PPD interface, some distros will not go CPDB and users complain when CUPS has another significant change or if a clod printing service with their CPDB backend shows up.
Are you aware of any specific reasons why distros would prefer direct use of CUPS API over CPDB other than the usual packaging efforts needed for any new library?
This ways distros have to go CPDB at a certain point of time. They can opt to switch over early, for a smooth transition to CUPS 3.x.
Yes, distro packagers should generally be able to judge best when it's the right time to switch.
GTK has no alternative CUPS-based backend. Only its original one and alternative is CPDB with CPDB's CUPS backend. This alternative is required for CUPS 3.x.I did not actually check the GTK dialog's CUPS backend code. I only observed that the GTK dialog is the only one not only showing the permanent CUPS queues but also the IPP print destinations for which CUPS creates a temporary queue on demand. I did not look into how the options and choices are obtained.Then it seems that they just plugged the problem "IPP destinations without permanent CUPS queue do not get listed" by using cupsEnumDests() but left all the rest untouched. This satisfies all needs for users of CUPS 2.x but will fail with PPD-less CUPS 3.x, requiring the use of CPDB for CUPS 3.x here, too.
Even better if the approach other projects take seems to be the same one as we're discussing for LibreOffice now. This should also provide a more uniform user experience (same printers + options show up regardless of the application/toolkit,...).
This means also that the only example known to me, which uses the "Dests" API of CUPS correctly is the CUPS backend of CPDB, even more important to driver forward that CPDB gets used everywhere.
Thanks for the hint, I'll keep that in mind.
Modern (driverless) printers seem to have a job-password IPP attribute. Print dialogs (and for them CPDB) should add support for that.On old printers Printer Applications (PAPPL, pappl-retrofit) should support generatring a job-password IPP attribute (from typical PPD file options) and report it.CUPS should pass on this attributes for print queues which support this kind of secured printing.So we should post feature requests for all these components.This would also improve the UI of print dialogs when you can type the PIN as a 4-digit number instead of selecting the digits with 4 dropdowns.
There's the existing [1], but I don't know whether that would still be the right place to report such things these days.
OK, let us keep it for now and make sure uses/packagers/admins using CUPS 3.x use CPDB. The CUPS/PPD interface could be automatically skipped at build time if there is no libcups2 present, as the CPDB part could be skipped if there is no cpdb-libs present. If both got built, one could have a choice in the settings (not in the print dialog itself, to avoid clutter) which one actually to use.(...)I think we can go this way, see above. Important is that libcups2 with its PPD APIs is not required to build LibreOffice with print functionality.
That sounds reasonable and shouldn't be a problem in general, but will of course need a closer look into the code to see whether CUPS-related code is already fairly local or currently spread all over the place right now, requiring some more refactoring or reconsideration.
We already have various `--enable-<feature>`/`--disable-<feature>` configure flags (some with autodetection if not passed explicitly) for various features. Adding additional ones for those cases should be fine and fairly straightforward.
(Details on how to configure things at build and run time can also be discussed later.)
Michael [1] https://bugs.linuxfoundation.org/show_bug.cgi?id=1393
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
