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
