Open Bug 1826311 Opened 1 year ago Updated 3 months ago

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

Categories

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

enhancement

Tracking

()

People

(Reporter: till.kamppeter, Unassigned, Mentored, NeedInfo)

Details

Attachments

(1 file)

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.

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

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Mentor: emilio

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.

Flags: needinfo?(jwatt)
Flags: needinfo?(emcdonough)

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.

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.

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?

Flags: needinfo?(till.kamppeter)

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.

Flags: needinfo?(till.kamppeter) → needinfo?(jwatt)

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.

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

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: