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
- Introduction
- The CUPS Temporary Queue Mechanism
- Legacy/Classic and Modern Printers
- Printer Applications
- Command Line Interaction with a Printer Application
- The Legacy Printer Application
- Using a Modern Printer with a Printer Application
- The Building Blocks of a Printer Application
- Debugging a Printer Application
- Bug Reporting
- 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.
CUPS' local server will be designed to be very lightweight for desktop usage. There will only be support for temporary queues (no manually created CUPS queues will be possible). There will not be any web interface and very little that can be configured.
- CUPS' sharing server will be very similar in functionality to the current CUPS 2.3/2.4, supporting permanent driverless queues and aimed at server use.
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:
cups-browsed: A daemon to auto-create print queues and to form printer clusters. Planned to be turned into a Printer Application eventually, but without the auto-creation feature.
cups-filters: Legacy filters for print data and legacy printer backends for CUPS 2.x.
libcupsfilters2: A central library containing common code for print data conversion filters, printer drivers, printer model identification, PDF file manipulation, PDF font embedding, color space conversion and more. It does not contain any support for PPD files.
libppd2: A library to support PPD files and convert PPD options into IPP attributes. Used by papple-retrofit and Printer Applications. This library is only for legacy PPD and driver support.
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
Note that testppd_desktop_new, ENVY4500 and RX420 are the names of printers discovered and enumerated by CUPS but are not (yet) queue names. However, they can be regarded as the names for prospective or potential queues.
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
Have its capabilities discovered on the network or USB via mDNS/DNSSD.
Communicate with CUPS using IPP.
In addition to JPEG, aaccept one of PDF, PWG raster or Apple raster as a PDL.
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
- runs as a daemon
- detects supported printers
advertises a supported printer on localhost or the network as an IPP Everywhere printer
provides a web interface (an EWS) to add a printer and configure its capabilities
- listens for requests to print a job
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.
- Setting up a printer and printing to it does not require CUPS to be on the host system.
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
- a queue name (chosen by the user),
a device URI (use hplip-printer-app devices),
a driver name (search the output of hplip-printer-app drivers),
- desired options.
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.
PAPPL
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
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
- Running filter
- exited
- Ghostscript and ghostscript
- Backend and backend
- argv
- error
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