Support for IPP and Printer Applications in CUPS Transition

Desktop
1

This Merge Request MR LINK is part of OpenPrinting’s work to adapt the “Printers” module of the GNOME Control Center to the changes in the architecture of the printing workflow.

Due to the fact that most modern printers are driverless IPP (Internet Printing Protocol) printers, CUPS is going away from supporting PPD files and driver filters, but it is going all-IPP and with this will support only driverless IPP printers. For the few specialty printers and the many non-driverless legacy printers still around, Printer Applications will be used. Printer Applications are software emulations of drivreless IPP printers which on the other end talk with the printer hardware, doing all needed conversions internally. This format is the replacement for the former printer drivers.

We add the following features:

In the main view we do not only display permanent, user-created CUPS queues, but also IPP print destinations (driverless network printers, IPP-over-USB printers, Printer Applications, shared remote CUPS queues, …) for which CUPS would auto-create a temporary queue when printing on them (equivalent of lpstat -l -e output). Action menus for these IPP print destinations are adapted, especially entry to directly open the destinations’s web admin interface.

In the “Add Printer” part we add functionality to discover (non-driverless) printers by polling installed Printer Applications and also to apply Printer Applications to a discovered printer as driver.

We add this functionality and do not remove the old one for smooth transition, as the current CUPS 2.x supports both architectures, and the future CUPS 3.x only the new one. Once G-C-C updated, CUPS can be updated at any time.

We also remove duplicate entries in main view of printer panel by changing printer discovery cups API used to a newer version.

2

The GNOME Control Center transition to CUPS 3.x logic effectively deprecates the local PPD filter chain. For legacy hardware support, ensure you have the appropriate Printer Application (PAPPL-based) running to encapsulate the driver. If discovery fails in the GCC panel, verify avahi-daemon status and check 1pstat -e to see if the IPP destination is being broadcasted correctly to the local CUPS scheduler

3

Yes, you are right. My merge request currently supports both CUPS 2.x and IPP printers/printer applications. This is the first step we have taken.

In the future, we will also implement automated downloading of the appropriate printer application based on the printer, especially for older devices. This will ensure that the behavior of the printer panel becomes consistent with the current functionality while also supporting the modern IPP printer protocol. thus finally we remove cups2.x

4

That is a solid roadmap. Implementing automated discovery and downloading of the appropriate Printer Application is definitely the missing link for end-user UX, especially for those of us still maintaining legacy hardware.

It’s good to know that the current MR maintains a dual-compatibility layer with CUPS 2.x for the time being. This should provide a sufficiently smooth transition period before the hard deprecation of the old architecture in CUPS 3.x.