Translation(s): none

Some material on this page has little immediate bearing on a user's printing experience on Debian 11 (bullseye) and 12 (bookworm). It is intended to give a taste of things to come and to encourage the testing of the snapped Printer Applications. Its content will inevitably require revision in the coming years.

Contents

  1. Introduction
  2. The CUPS Temporary Queue Mechanism
  3. Legacy/Classic and Modern Printers
  4. Printer Applications
  5. Command Line Interaction with a Printer Application
  6. The Legacy Printer Application
  7. Using a Modern Printer with a Printer Application
  8. The Building Blocks of a Printer Application
  9. Debugging a Printer Application
  10. Bug Reporting
  11. See Also

Introduction

Within one or two years the complexion of the printing system on Debian will undergo fundamental change with the release of CUPS 3.0. This version will no longer support printing with PPD files and therefore, by implication, not support vendor drivers, whether they be free or non-free. Drivers will still exist, but they will come in a new format as a Printer Application from OpenPrinting. The focus will be completely on supporting only standards-conforming driverless IPP printers.

CUPS 3.0 will also have a modular printing architecture that includes the introduction of a local server and a sharing server.

For either a local or sharing server, that means using the printer-driver-* packages in conjunction with this advice on print queue creation will no longer work.

The core filtering functionality of cups-filters and cups-filters-core-drivers will be kept but be moved into libcupsfilters. There will also be other major changes to cups-filters to adapt it to a PPD-less printing system having Printer Applications. Overall, the purposes of the New Architecture's proposed new binary packages will remain the same as with cups-filters 1.28.x. Briefly:

The New Architecture envisages: 

+------------+   +----+   +-------+   +--------------+
|            |   |    |   |Filters|-->|Modern Printer|
|    User    |   |    |   |   +   |   +--------------+
|Applications|-->|CUPS|-->|  ipp  |
|            |   |    |   |backend|   +-------------------+   +--------------+
|            |   |    |   |       |-->|Printer Application|-->|Legacy Printer|
+------------+   +----+   +-------+   +-------------------+   +--------------+

The CUPS Temporary Queue Mechanism

Temporary queue formation by CUPS is such an important part of the New Architecture that some detailed examination is deserved.

Since version 2.2.4, mDNS/DNS-SD allows CUPS to discover and browse the shared print queues advertised by a CUPS server and the multicasts of IPP printers exposed on the network.

Discovery and browsing is performed by avahi-daemn. Printing requires hostname resolution, which is done with libnss-mdns. Packages to implement these services are provided by a default printing system.

To explore the operation of the temporary queue mechanism it is necessary to stop or remove cups-browsed from the system: 

systemctl stop cups-browsed
apt remove cups-browsed

This is because a default cups-browsed will, in auto-creating local queues, take over the names of enumerated printers and effectively remove them from the control of CUPS and prevent the temporary queue mechanism from being put into action. See the LocalQueueNamingRemoteCUPS and LocalQueueNamingIPPPrinter directives in cups-browsed.conf.

For a view of all available destinations on the local network: 

brian@test-new:~$ lpstat -l -e
ENVY4500 network none ipp://ENVY4500._ipp._tcp.local/
RX420 network none ipps://RX420._ipps._tcp.local/
testppd_desktop_new network none ipps://testppd%20%40%20desktop-new._ipps._tcp.local/cups
testq-1 permanent ipp://localhost/printers/testq-1 tea4cups:/

The destination testq-1 is designated as permanent. This indicates a local print queue and isn't of any further interest. Printer destination testppd_desktop_new is a non-local queue shared by a CUPS server on host desktop-new. The ENVY4500 and RX420 destinations are IPP printers on the network. (RX420 is actually a Printer Application).

To see local print queues: 

brian@test-new:~$ lpstat -a
testq-1 accepting requests since Mon 10 Apr 2023 14:21:57 BST

Printing to any of these three IPP printers involves querying the printer for its attributes. Querying is possible with 

lpotions -p <destination> -l

A PPD and a local queue should be created: 

brian@test-new:~$lpoptions -p RX420 -l
(PPD output deleted).

brian@test-new:~$ lpstat -a
RX420 accepting requests since Sun 16 Apr 2023 15:37:37 BST
testq-1 accepting requests since Mon 10 Apr 2023 14:21:57 BST

A temporary local queue for RX420 has been created. Check with lpstat -a that it disappears after about a minute.

Users mainly employ cups-browsed on CUPS 2.x as a way of automatically installing discovered printers. With CUPS 3.0 cups-browsed will not work for this purpose any more as its auto-creation of a classic queue with a PPD file will not be supported.

Legacy/Classic and Modern Printers

A legacy or classic printer requires a PPD to describe its capabilities and, in the case of non-PostScript printers, a vendor-specific driver. That would imply having to have a PPD/driver for every printer encountered and the printing system has been burdened with this task.

In contrast, a modern printer can

A printer fulfilling these three conditions is normally referred to as driverless. Driverless printing does not mean filrerless printing. Indeed, all needed filters are on every Debian system and, if necessary and called on, can convert a print job to a PDL acceptable to the printer. No more vendor PPDs and vendor PDLs (often proprietary) need to be employed for printing with a driverless printer.

One criterion for determining whether a printer is modern is to ascertain whether it is capable of AirPrint. This is because the criteria for AirPrint certification are the same as those demanded of driverless printing.

Unfortunately, there are are driverless printers that are not registered as AirPrint-capable. In this case, it is advised to execute avahi-browse -rt _ipp._tcp and consult the pdl= key. The presence of image/urf or image/pwg-raster would indicate a driverless printer.

Users of modern printers with CUPS 3.0 and the New Architecture should have a printing experience that is basically the same as with CUPS 2.3/2.4 on Debian 11 (bullseye) and later. Users of legacy printers will require a Printer Application.

Printer Applications

A Printer Application emulates an IPP printer. It

The job is then handled by the supported printer's PPD and driver needed for the legacy printer to operate. The classic software is built into the Application. For example, hplip-printer-app essentially contains the same printer drivers, PPDs and software to communicate with the printer hardware (but not any of its GUI tools) that is in hplip. A simple example of a Printer Application is given on this page.

The Printer Applications are developed by OpenPrintig and practically every free printer driver that is available as a Debian package is also available in the present Printer Applications. None are as yet packaged for Debian, but it is possible to assess their role in printing on CUPS 2.3/2.4 and cups-filters .1.28.x by installing snapd and going to the Snap Store for an Application. 

apt install snapd
snap install --edge ps-printer-app

The Application's EWS is accessed with 

http://localhost:8000

With more than one Application present the port number increments by 1; 8001, 8002 etc.

Now activate the Add Printer link. The legacy printer should be discovered and listed. Either allow Auto-Detect Driver or choose a driver. Give the printer a Name and add it. These steps can be carried out without root privileges. The PRINTER_NAME should be visible in the dialogs of applications.

The printer's existence can be confirmed with 

avahi-browse -rt _ipp._tcp 
lpstat -l -e

The second command requires CUPS to be on the host or client.

Printing to it may be tested with 

lp -d PRINTER_NAME /etc/nsswitch.conf
ps-printer-app submit -d PRINTER_NAME ANY_PDF_FILE

The second command is for execution on a host with and without CUPS present.

Command Line Interaction with a Printer Application

Taking the hplip-printer-application as an example, run 

hplip-printer-app --help

The capabilities of the device are listed: 

Usage: <application-name> SUB-COMMAND [OPTIONS] [FILENAME]
    <application-name> [OPTIONS] [FILENAME]
    <application-name> [OPTIONS] -

Sub-commands:
add PRINTER      Add a printer.
cancel           Cancel one or more jobs.
default          Set the default printer.
delete           Delete a printer.
devices          List devices.
drivers          List drivers.
jobs             List jobs.
modify           Modify a printer.
options          List printer options.
printers         List printers.
server           Run a server.
shutdown         Shutdown a running server.
status           Show server/printer/job status.
submit           Submit a file for printing.

Options:
-a               Cancel all jobs (cancel).
-d PRINTER       Specify printer.
-j JOB-ID        Specify job ID (cancel).
-m DRIVER-NAME   Specify driver (add/modify).
-n COPIES        Specify number of copies (submit).
-o NAME=VALUE    Specify option (add,modify,server,submit).
-u URI           Specify ipp: or ipps: printer/server.
-v DEVICE-URI    Specify socket: or usb: device (add/modify).

Let's install a print queue in the Application. This is a matter of providing

Provision of the first three items is obligatory; providing the fourth is optional.

PAPPL has its own backends built in. pappl-retrofit can use these, but, additionally, can choose CUPS backends. The later are accessed by modifying DEVICE-URI and adding cups: to the original URI. Like so: cups:DEVICE-URI. This scheme is used below.

For best compatibility with the CUPS drivers, it is suggested to specify the CUPS backends for communication with the printer hardware. This is done in the following command.

Finally, execute 

hplip-printer-app add -d CHOSEN_DEVICE_NAME -v cups:DEVICE-URI -m DRIVER-NAME -o OPTION_NAME=VALUE

Consult this User Manual for other command line operations and the HP Printer Application Documentation for -o NAME=VALUE options that may apply to hplip-printer-app. Also take a look at the output of hplip-printer-app optionns.

The Legacy Printer Application

The Legacy Printer Application was devised to cater for any legacy/classic drivers that are not covered by the existing four Printer Applications. It is a part of pappl-retrofit and makes already installed legacy/classic drivers (free and non-free) available in a Printer Application. The drivers consequently become available to CUPS 3.x. It can operate as an auto-starting, permanently running system daemon and comes with a systemd service file.

For example, many free legacy Epson divers are in gutenprint-printer-app, but those that are not are probably in printer-driver-escpr. Installing this later package results in the Legacy Printer Application seeing all the classic Epson CUPS drivers, filters, backends and PPDs included in printer-driver-escpr. The Application's web interface completes the setup process by installing a print queue within the Application.

The Legacy Printer Application also provides the same solution for users of classic non-free drivers from vendors such as Brother and Canon when the appropriate vendor package is on the system. The proprietary package becomes usable with CUPS 3.x in the same way as all printer-driver-* packages.

The Legacy Printer Application cannot be snapped as it needs access to the system's classically installed driver.

Using a Modern Printer with a Printer Application

The problem that a Printer Application is intended to solve is keeping as many legacy printers as possible usable with CUPS 3.x. As indicated diagramatically elsewhere, a user with a modern printer on the network or USB should be well served by CUPS 3.x. However, situations may arise that require a modern printer to be used via a Application.

Consider a situation in which a user experiences a problem on driverless printing that is not present with the vendor drivers. Perhaps there is a printer firmware bug that the vendor works round in its drivers, as appears to be the case here. If desired, the Legacy Printer Application has the potential to come to the rescue of that user.

It is the firm, considered opinion of upstream CUPS that vendors should attend to any firmware bugs in their printers. Nevertheless, in spite of any difficulty in coming up with a workaround for a broken device and having possibly to maintain it forever, a fix has been implemented for some issues. However, without a firmware update from a vendor fixing an issue, a user might have to resort to using a Printer Application with some printers.

It can be virtually guaranteed that a modern network capable printer with a USB connection will provide the IPP-over-USB protocol, but not so with a USB-only device of recent manufacture. Some USB-only printers do have IPP-over-USB; some don't. Those with IPP-over-USB are modern devices; those without it basically behave as legacy printers and need to use an Application. Furthermore, there isn't any easy way for a user to discover protocol capability at the time of purchase. It is usually after some troubleshooting that the unwelcome news is revealed.

It is very likely that CUPS 3.x plus a modern printer will answer the printing needs of most users. On the other hand, given a special task, intricate photographic production, for instance, the vendor drivers of an Application might take better advantage of a printer's resources and could be more suitable for the task.

The Building Blocks of a Printer Application

Although the vast majority of users will never get involved in building a Printer Application, it might be of interest to be aware of the parts played by two crucial libraries, PAPPL and pappl-retrofit.

This library is a framework for developing CUPS Printer Applications based on the IPP Everywhere protocol. It is intendedd as the replacement for classic printer drivers. It includes an implementation of IPP Everywhere, allowing driverless access to printers locally via USB or on the network (ethernet and WiFi) and the processing of print requests. In other words, an important part of its function is to emulate an IPP printer.

Printer discovery is undertaken and suitable printer drivers are searched for. Printer configuration is provided by an EWS (a web interface) and there is debug logging. There is also support for Windows 10 and 11 platforms.

pappl-retrofit produces specific Printer Applications and completely relies on PAPPL to aid it by supporting PAPPL's full functionality. PAPPL provides general functionality for a Printer Application whereas pappl-retrofit adapts classic CUPS drivers and PPD files to the basic Printer Application framework so that CUPS can make use of them. The pappl-retrofit library was developed alongside the four Printer Applications ps-printer-app, ghostscript-printer-app, hplip-printer-app and gutenprint-printer-app and is used as the basis for them.

The EWS of a Printer Application lists all user-settable options of the PPD file, paper input trays, paper size and type and whether borderless printing should be done, if supported. Drivers can be assigned to the discovered printers automatically or manually.

Debugging a Printer Application

Taking hplip-printer-app as an example, logging takes place in /var/snap/hplip-printer-app/common/hplip-printer-app.log. The other snapped Applications do not log to /var/log/ either. Root privileges are need to read the log. Setting the Log Level from the web interface as a user is possible.

Useful terms for searching hplip-printer-app.log are

Error lines in the log can be found with 

grep ^E /var/snap/hplip-printer-app/common/hplip-printer-app.log

Should a file be needed to send to a bug report, it might be considerate to empty the existing file with 

>/var/snap/hplip-printer-app/common/hplip-printer-app.log

before producing the log.

Bug Reporting

See Also

CategoryPrinter