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.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Sidebar in print preview

Hi, Till!

Trying to make sure I understand what's being requested here. Firefox (and Thunderbird) both have a non-native cross-platform print preview UI that it offers to users when initiating a print. Within that UI, there is a link to "Print using the system dialog" (see the attached screenshot).

Clicking that opens up a native print dialog (which on the Linux platform tries to do this with Gtk).

Am I to understand that this system dialog is the one that you'd like to be configurable via CPDB?

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jwatt, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Till Kamppeter]

Sorry for the late answer, seems that I did not get a notification.

The system print dialog which you get by the link, meaning for Linux the GTK dialog is already supporting CPDB, from on current GTK 4.

What I also like to have CPDB on are all the application's native dialogs in Linux (and generally Posix-style operating systems). There are not many, most apps use the dialogs of GNOME/GTK and KDE/Qt, which are taken care of, to my knowledge the apps with their own dialogs are Chromium Browser, LibreOffice, and Mozilla (Firefox/Thunderbird). We want them all use CPDB so that if there is a significant change in CUPS, like currently the New Architecture which goes all IPP and abolishes classic drivers with PPD files, we at OpenPrinting update the CPDB backend for CUPS along with CUPS and that way assure that the desktop print dialogs are immediately working with the new CUPS, and if somebody introduces a cloud printing service, they only need to publish a CPDB backend and the service gets available in all the print dialogs. So the responsibility of the print dialogs supporting each print system correctly gets delegated to the developers of each print system, who also develop the corresponding CPDB backend.

So for Mozilla this means that with this bug report I request the feature of adding CPDB support to Mozilla's own print dialog, the one with the preview, which you are showing in the picture.

CPDB does not need to support previews for that, the preview continues to be generated by the dialog itself. CPDB provides access to the list of available printers, the capabilities and user-settable options of each printer, and an interface to send off the jobs to the desired printers, and that all in a way independent of the actual printing system being used (CUPS, a cloud printing service, ...). So on the following operations of your dialog you do not use the CUPS (libcups) functionality any more, but instead, the corresponding functionality of CPDB (cpdb-libs):

• Get a list of all available printers
• For a selected printer, get a list of all options and available choices for each option
• For a selected printer, send off a job to the printer

CPDB has also auxiliary functions to obtain human-readable option and choice names, translations, unprintable margins, ...

That is all you need. For the preview you poll the options of the selected printer to get the page size and the fact whether we print in grayscale or color, and in addition, you poll the unprintable margins.

So you should be able to replace all communication with CUPS by communication with CPDB.

Comment 8

[Till Kamppeter]

Hi, @mconley, we did not hear from you for some time. Is there anything still missing from me? If so, please tell me.

Comment 9

[kushagrasharma30072001]

Hi everyone,
I hope this message finds you well. My name is Kushagra Sharma, and I am writing to introduce myself and express my interest in contributing to Mozilla Firefox by adding Common Print Dialog Backends (CPDB) support.

I was a contributor to Google Summer of Code (GSoC) 2023, where I successfully added CPDB support to Chromium. This project is currently under review and has been well-received by the community. My experience working on Chromium has equipped me with a deep understanding of CPDB and its integration into web browsers.

Building on this experience, I am eager to extend CPDB support to Mozilla Firefox. I believe this integration would enhance the printing capabilities of Firefox and provide a more consistent user experience across different platforms.

To get started, I would like to review the current implementation of the print backend in Mozilla Firefox. Could you please guide me on where to find the relevant documentation and codebase? Any pointers or initial guidance would be greatly appreciated.

Thank you for considering my request. I am excited about the possibility of contributing to Mozilla Firefox and look forward to your response.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Let me try to give you a proper response early next week. Thanks!

Comment 11

[Emilio Cobos Álvarez (:emilio)]

To get started, I would like to review the current implementation of the print backend in Mozilla Firefox. Could you please guide me on where to find the relevant documentation and codebase? Any pointers or initial guidance would be greatly appreciated.

So, there's a lot that happens before, but when printing a page we basically do a static copy of the document, and create a print job, which eventually ends up in nsPrintJob::DoPrint (here).

By that point we've already created a PrintTarget (like PrintTargetPDF or PrintTargetCG or ...) and received an appropriate nsPrintSettings object from the front-end.

In terms of the print dialog, which might be more interesting for you... The Firefox print dialog is in toolkit/components/printing/content/print.html, and the relevant JS code is print.js, which basically takes care of mapping the dialog into an nsPrintSettings object, and eventually call into gecko for printing.

The code to use the system dialog is here, which eventually gets here, and eventually in a per-platform PrintDialogService::ShowPrintDialog.

So it seems the way we'd proceed here would be to add a pref, and change nsPrintServiceGTK::ShowPrintDialog to do whatever you need to do? Not sure off-hand if you'd need to extend other parts of the codebase, but we can probably work through that as needs arise.

Hopefully that helps? Let me know if that wasn't what you were looking for, or if you need any extra details or what not.

Comment 12

[Emily McDonough [:alaskanemily]]

Depending on what you mean by "print backend", you might also need to implement an nsPrinterList https://searchfox.org/mozilla-central/rev/64ddb621a0d3905fc2e3df475517d4163d377b22/widget/nsPrinterListBase.h which is how we enumerate printers and their properties, and where we do most of our CUPS work.