1826311 - Print Dialog: Add support for the Common Print Dialog Backends (CPDB)

Status: NEW

(Core :: Printing: Setup, enhancement, P3)

Description

[Till Kamppeter]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

I am Till Kamppeter, leader of OpenPrinting and so responsible for the printing infrastructure in Linux and other Posix-style operating systems.

https://openprinting.github.io/about-us/

Firefox and Thunderbird (probably all Mozilla applications on the Linux desktop) are under the few applications which have their own print dialog, and do not use one of the desktop environment toolkit's (GTK/Qt) ones primarily (AFAIR one can use the GTK one optionally, via a link/button in Mozilla's print dialog). Here a change is needed to assure smooth and easy printing in the future.

Now, after 22 years of CUPS with PPD files and print filter executables as printer drivers we have a change in the print architecture. The use of PPD files gets abolished in CUPS and CUPS will go all-IPP, due to the fact that modern printers are driverless IPP printers, which tell everything about their capabilities to the clients via IPP (so do not need PPDs) and use standard file formats for print jobs (and so do not need driver filters). This requires changes in print dialogs.

https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning

As this is most probably not the last major change needed and also for print dialogs to support other print technologies than CUPS, for example cloud printing services, I have created already 5 years ago, the concept of the Common Print Dialog Backends (CPDB):

https://openprinting.github.io/achievements/#common-print-dialog-backends

Here the print dialog does not talk directly with the print technology (like CUPS) but there are GUI-toolkit-independent backends, usually maintained by the maintainer/developer of the print technology (OpenPrinting for CUPS and for print-to-file). This way the maintainer of the print technology, when they change something, they also change the backend appropriately and all print dialogs immediately work with the change. And if someone introduces a cloud printing service, they simply put the backend for it into the Snap Store and once installed the user can use the service from any print dialog.

Now, with the upcoming New Architecture for printing and scanning there was a need of change on all print dialogs and I decided to finally get CPDB be used in all print dialogs, and found a great, enthusiastic GSoC (2022) contributor for it. He implemented the support in both GTK and Qt dialogs and succeeded to get the merge request on the GTK one accepted upstream.

https://github.com/TinyTrebuchet/gsoc22/
https://openprinting.github.io/OpenPrinting-News-February-2023/#common-print-dialog-backends-support-accepted-into-gtk

For this he did not only work on GTK and Qt code but also on the development of CPDB, creating a second generation with much more functionality:
https://openprinting.github.io/Common-Print-Dialog-Backends-Second-Generation-First-Beta-Release/

My Feature Request now is to get CPDB support into the print dialog of Mozilla, so that users of Firefox, Thunderbird, and other Mozilla applications will be able to continue to easily print also after the transition to CUPS 3.x (or to the CUPS Snap, which also does not support classic CUPS drivers/PPD files) and also print with any upcoming cloud printing technology right out of the print functionality of the Mozilla applications.

If the choice of "Core" for the product and "Printing: Setup" for the component is wrong, please correct.

I can also help with the implementation as I have a contributor who would do the coding, he only needs somone mentoring/guiding him to do the code contribution to Mozilla correctly.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I'd be happy to mentor fwiw. Another potential approach here is using the print portal here, right? But IIRC last we checked that wasn't flexible enough, so we had to enable cups access instead and use our cups back-end (bug 1712555).

Comment 2

[Frank Griffith Jr]

Till, I'm the Eng Mgr for the Layout Team. Let me gather my experts on this and give you some feedback on whether this is something we are willing and able to pursue.

Comment 3

[Emily McDonough [:alaskanemily]]

I'm definitely not against this idea. CUPS has been a lot of trouble to integrate and actually have work well with many printers.

One thing I'll note is that we do have tentative plans (or just ideas for the future) to implement our own IPP backend rather than using the CUPS client library at some point.

We've found that CUPS can be difficult to deal with in an application like Firefox: it often requires us to craft our own IPP requests to determine printer details, its threading model requires extra work to integrate and requires extra work to use in a thread-safe manner within Gecko, and its HTTP library and scheduler duplicates a lot of functionality already present in Gecko.

I would hope that this would reduce the first kind of work (having to drop down to IPP requests directly), but I worry it would be just as much trouble as CUPS (or more) to make it work nicely with Firefox's threading and multiprocess architecture.

It also seems like many Linux systems aren't even on CUPS 2 yet, so this would at best live alongside a CUPS (or our own IPP code) for quite some time. This seems to be in a better situation for BSD systems, at least.

Comment 4

[Till Kamppeter]

Sorry for the late answer I was busy the last days, especially with the Linux App Summit 2023 in Brno, Czech Republic.

First, portals. like xdg-desktop-portal are not the ultimative solution as, AFAIK, they are only available in sandboxed packaging, Flatpak and Snap, distros who stay with their classic packaging, like Debian or RPM, for Firefox and Thunderbird will not have a portal for these available.

The Common Print Dialog Backends do not only make print technology support exchangeable and addable and move responsibility on printing technology support to the maintainers of the print technologies, but also de-couple the libcups use from the application. I do not know whether the threading behavior of the CPDB libraries is actually better, but at OpenPrinting we are open to still needed functions if needed.

Are there really still distros using CUPS 1.x? I assumed that at least desktop Linux distributions all use CUPS 2.x. CUPS 3.x is actually not completed yet. But even without CUPS 3.x, CUPS 2.x for example has the concept of temporary queues for IPP print services, and with CPDB these get displayed. Generally the current CPDB backend for CUPS supports both CUPS 2.x and CUPS 3.x.