Adding support for the Common Print Dialog Backends (CPDB)

[Till Kamppeter]

On 27/03/2024 12:55, Michael Weghorn wrote:
> 
> For CUPS 3.x support, my initial thought was that requiring the CPDB-based 
> implementation for that could be a way forward, while leaving LO's internal 
> CUPS/PPD implementation basically unchanged and around for compatibility reasons 
> (for CUPS 2.x setups only) as long as necessary.
> 
> The CPDB implementation would then be optional for CUPS 2.x, but required for 
> CUPS 3.x.
> 
> If the CPDB approach will cover everything that the current CUPS/PPD 
> implementation does (does it?), that could avoid the need to spend extra effort 
> on LibreOffice's CUPS/PPD implementation.
>

OK, let us go this way.

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.

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.

> 
> Thanks for explaining what would be needed.
> 
>  From a first glance at the GTK 4.x code, I'm a bit surprised by it being 
> referenced as an example of how to implement things properly.
> 
> While I see it has a CPDB implementation (initially added in [1]), its own CUPS 
> print backend implementation (e.g. in [2] and [3]) seems to be full of uses of 
> deprecated API, including direct use of PPDs.
> [2] even has this comment at the top:
> 
> /* Cups 1.6 deprecates ppdFindAttr(), ppdFindCustomOption(),
>   * ppdFirstCustomParam(), and ppdNextCustomParam() among others.
>   * The replacement is to use the Job Ticket API, but that requires
>   * a larger refactoring of this backend.
>   */
> 
> Is there another CUPS-based implementation (besides the CPDB-based backend) or 
> am I missing anything else here?
> 

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.

Thanks for checking this.

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.

Note that the tryPPD() function in the CPDB CUPS backend seems only to be a 
debug crutch or a remainder of old code. It only logs a list of the options in a 
queue's PPD file and does not change anything in the print dialog. As it only 
causes unnecessary compiler (API deprecation) warnings and would cause a 
dependency on libppd when switching to libcups3, I asked Biswadeep to remove it.


>> 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), (...)
> 
> Does that include cases like [4]? And if so, what would be the requirements for 
> that to work (as it didn't work in the past)?
> 

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.

> In general, my opinion is that for LibreOffice's existing CUPS/PPD 
> implementation, we should be very careful not to risk to break existing (legacy) 
> setups.
> 

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.

> To me, the potential approach outlined above (envision to fully move to 
> CPDB-approach in the longer run, leave existing CUPS/PPD implementation 
> basically unchanged and around as long as needed so things work "as they always 
> did" for legacy setups) seemed to match well with that idea, but I'm certainly 
> not as knowledgeable about how this all works as you are, so would appreciate to 
> hear your (and anyone else's) opinion on that.
> 

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.

> 
> Thanks, I've done that right after registering. The proposal looks good to me.
>

Great to hear. Thanks for reviewing.

    Till