Adding support for the Common Print Dialog Backends (CPDB)

[Michael Weghorn]

On 2024-03-27 11:27, Till Kamppeter wrote:
> 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).

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.

> 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.

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?

> 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)?

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.

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.


> 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.

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

> You will do the LibreOffice side of the mentoring, Gaurav Guleria and me 
> will do the CPDB side.

That sounds great, thank you!


[1] 
https://gitlab.gnome.org/GNOME/gtk/-/commit/41b60bbd6ceb36dfc22e625d2b3c65bd45f15c76
[2] 
https://gitlab.gnome.org/GNOME/gtk/-/blob/b1eed1c153f7553c353dc77ae2b0154bdcedc8a0/modules/printbackends/gtkprintbackendcups.c
[3] 
https://gitlab.gnome.org/GNOME/gtk/-/blob/b1eed1c153f7553c353dc77ae2b0154bdcedc8a0/modules/printbackends/gtkprintercups.c
[4] https://github.com/apple/cups/issues/4969
-------------- 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/2eac2c9e/attachment.sig>