Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20240327/9e3927c6/attachment.sig>