Partially rewrote "Creating a Driverless Print Queue with lpadmin".
A new section: CUPS 2.2.4 and Driverless Printing.
|Deletions are marked like this.||Additions are marked like this.|
|Line 161:||Line 161:|
=== CUPS 2.2.4 and Driverless Printing ===
CUPS' ability [[PrintQueuesCUPS#tempq|directly to browse]] the DNS-SD (Bonjour) broadcasts of remote print queues and printers, previously absent, was introduced in CUPS 2.2.4. This means that a system with CUPS 2.2.4 or later (such as Debian 10.x.x) will display remote queues and printers with `lpstat -e` and in the print dialogs of some applications without [[PrintQueuesCUPS#cups-browsed|cups-browsed]] (needed on Debian 8.x.x and Debian 9.x.x for remote queue management) being on the system. No action on the part of the user is required.
Essentially, CUPS uses its !CupsGetDests and !CupsEnumDests functions to discover shared queues and printers which can be printed to on the local network and makes them available for display in an application. Whether or not the application displays them depends on the chosen application. Printing to an enumerated entry leads to the formation of a [[PrintQueuesCUPS#tempq|temporary queue]].
* `lpstat -a` only shows queues of the local CUPS daemon and not DNS-SD advertised queues or printers. `lpstat -e` and `lpstat -l -e` additionally enumerate queues and printers which can be accessed on the network.
* The Qt print dialog of applications like Okular enumerate remote, shared queues and printers and uses a temporary queue for printing.
* The Libreoffice print dialog behaves the same way as the Qt dialog.
* The print dialog of GTK applications such as Firefox and Evince does not function in the same way as the Qt and Libreoffice dialogs. It obtains queue and printer information directly from DNS-SD broadcasts and not through CUPS, so it has no knowledge of what CUPS 2.2.4 and later are capable of doing.
Let us consider the behaviour of the GTK print dialog in a little more detail. The applications using it produce a PDF with DebPkg:libcairo2. A Debian CUPS server will have no trouble accepting and printing this PDF when it is sent to a remote queue listed in the dialog. If the entry is a remote printer, the printer has to be able to accept and process the PDF. This might not be the case, so the dialog will display
print <Location> Rejecting Jobs
A [[#misc|check with avahi-browse]] might reveal for the printer:
showing that PDF is not an accepted [[#pdls|Page Description Language]].
The solution is to put [[#cupsbrowsed|cups-browsed]] on the system and, in [[DebianMan:cups-browsed.conf|cups-browsed.conf]], have cups-browsed create permanent, local queues (rather than the CUPS temporary queues) for remote queues and printers with
It very likely that only the entry for the remote printer is wanted, so alter ''cups-browsed.conf'' to have
Note that managing queues and printers in the GTK dialog in this way also leads to other dialogs and the command line utilities following suit.
Driverless printing with CUPS. Requires at least CUPS 2.2.2 and version 1.13.0 of cups-filters.
- The Concept of Driverless Printing
- Driverless Printing and Printers
- PDLs for Driverless Printing
- CUPS: PWG and Apple Raster
- Creating a Driverless Print Queue with lpadmin
- Creating a Driverless Print Queue with the CUPS Web Interface
- Creating a Driverless Print Queue with system-config-printer
- Creating a Driverless Print Queue with cups-browsed
- CUPS 2.2.4 and Driverless Printing
- CUPS and Driverless Printing: Miscellaneous
- See Also
The Concept of Driverless Printing
Driverless printing is targeted at the client side of printing and refers to the ability of the client device (computer, smartphone, tablet, laptop etc) to print without having to install any static capability files or drivers (manufacturer-specific or otherwise) on the client.
There is a variety of methods for a client to submit a job to a driverless printing system:
- Web print. The document is uploaded from a web browser via a web form style interface.
Print directly from an application on the client.
- Send the job as an email attachment to a special address.
Use a cloud service such as ?Google Cloud Print (GCP).
This page is intended to highlight and explain driverless printing using packages provided by Debian so not all these methods will receive attention here. Furthermore, details for using iOS and Android mobile clients are not treated.
Driverless Printing and Printers
A traditional printing system based on CUPS, cups-filters and cups-browsed generally obtains information about printer features and capabilities from what is stored in a static capability file such as a PostScript Printer Description (PPD) file. This static file is stored on the client device (desktop computer, laptop, tablet etc) itself. If the PPD on the client requires the sending of a job using a non-standardised Page Description Language (PDL) a driver would be required for converting to the printer-specific PDL and that driver too would have to be on the client. A client that regularly connected to different printers would have to maintain static capability files and drivers for each printer.
This is not seen as an acceptable situation for mobile clients, which may have limited storage for PPDs and drivers and which may lack resources, such as battery power. Neither is it deemed particularly realistic for a user to have to set up or reconfigure a mobile device for each printer that is encountered. This requires a level of expertise and a time and effort commitment that cannot be assumed to be possessed.
The response of printer manufacturers to the desire for driverless printing has been to enhance their printers in the following way:
The printer advertises its presence and capabilities with mDNS/DNS-SD (Bonjour). This is the discovery protocol; accessible printers can be identified and selected from the Bonjour broadcasts of the printer.The discovery protocol is also configured to obtain capability information from accessible printers to include in its broadcasts.
The client and printer communicate using the IPP protocol. This is the transport protocol; it can obtain capability information from the selected printer and transport data to the selected printer.
There is a common PDL (Page Description Language) that the client can send and that the printer will accept. The common PDL is based on what is obtained from the capability information for the selected printer. A driverless-enabled printer will offer at least one of Apple raster, PWG raster, PDF or PCLm as a PDL.
Note that we are talking here about sending a job directly to a printer, not to a print queue being advertised by CUPS.
PDLs for Driverless Printing
Two raster formats, Apple raster and PWG raster, have been developed to implement driverless printing.
In the case of PWG raster the raster format was chosen because it is a simpler format than that of the high-level languages, which also require significant resources on the printer. Printer-embedded PostScript interpreters can be buggy and/or slow and PostScript also has the disadvantage that it makes interoperability between client and printer difficult because PostScript does not fit cleanly with the IPP and PWG models. Streaming was chosen to send a job to a printer rather than generating a file that is downloaded and then printed. This way large jobs don't take up too much memory or storage space on the printer and printing commences with minimum delay.
Apple raster has existed for a number of years and is used with Apple's AirPrint. Unfortunately, it is not officially documented but it is known that it and PWG raster are very similar. The MIME media type is image/urf.
CUPS: PWG and Apple Raster
The abilitity to create Apple raster files has been added to the existing PWG raster support in CUPS and made its appearence in CUPS 2.2.2; this enhancement was soon applied in version 1.13.0 of cups-filters and cups-browsed. Complete support for IPP Everywhere printers was already in Debian, so, with CUPS 2.2.2, AirPrint printers joined the class of printers that will work driverless with Debian.
With the incorporation of the two raster formats as a PDL in CUPS, IPP 2.0 to allow for querying the capabilities information from the printer and Bonjour/DNS-SD to find the printers in the network, Debian has everything needed for driverless printing to an IPP printer.
The processing of a job to create an Apple raster file is taken care of by CUPS' rastertopwg filter. The file produced by the filter is sent directly to the printer with IPP so no vendor-specific filters are involved. This opens up the possibility of avoiding the use of non-free drivers on the server used for printing.
Creating a Driverless Print Queue with lpadmin
Some familiarity with a device-uri is assumed in this section.
With a single AirPrint printer on the network a partial output from lpinfo -v could be:
network dnssd://HP%20ENVY%204500%20series%20%5BFAFAC2%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2 network socket://192.168.7.235:9100 network ipp://envy4500.local:631/ipp/print
The snmp backend has found the printer will accept jobs on port 9100 (socket://192...). Queues using this device-uri would need to be set up with a PPD specified with the -m or -P option of lpadmin, so would not be driverless.
The ENVY 4500 has also been discovered from the printer's Bonjour broadcasts using the dnssd and ipp backends. Both these URIs are equally stable and can be used for driverless printing, with a dnssd URI being preferred if the ipp URI is using a numeric IP address.
ippfind (Shows IPP printers and print queues). ippfind -T 5 (Possibly more reliable). ippfind ! --txt printer-type (Show IPP printers only). driverless (To get the device-uri). driverless list (For the device-uri and printer metadata). driverless device-uri (Generate a PPD for the printer at device-uri).
A queue for driverless printing from a client is now set up with
lpadmin -p <print_queue_name> -v <device-uri> -E -m everywhere
The everywhere model causes the printer referred to by the -v option to be queried. A list of printer capabilities is returned and a PPD is automatically generated by CUPS for use by command line programs and applications.
If the -v option is the URI of a queue on a remote CUPS server, this technique can create a driverless queue on the client for a remote non-raw queue. This is the method employed when CUPS sets up a temporary queue on a client.
Creating a Driverless Print Queue with the CUPS Web Interface
Some familiarity with the CUPS web interface is assumed in this section.
Open the web interface and choose Administration. Select Add Printer and log in.
Your printer will be under the Discovered network Printers:, probably with more than one entry. Choose the entry that contains the word driverless and move on to Continue.
Check that Connection is ipp://... and continue to the next page.
Model should have been be chosen for you and contain the word driverless. Add the print queue (a PPD is auto-generated) and set the default options for it on the next page.
Creating a Driverless Print Queue with system-config-printer
Some familiarity with system-config-printer is assumed in this section.
Start system-config-printer and choose Add followed by Network Printer.
An AirPrint or IPP Everywhere printer will probably be listed with a .local suffix.
Highlight the entry and check that the device URI begins ipp://... .
Moving on has system-config-printer searching for a driver, auto-generating a PPD and offering a screen to describe the printer. Choose Apply when done.
Creating a Driverless Print Queue with cups-browsed
This method leads to a fully automatic discovery of an AirPrint or IPP Everywhere printer, sets up a print queue and creates a PPD for it. The PPD is used to display printer options for command line programs and in applications. There are just two operations a user has to carry out.
Edit /etc/cups/cups-browsed.conf to set the CreateIPPPrinterQueues to all or driverless and restart cups-browsed.
CreateIPPPrinterQueues all or CreateIPPPrinterQueues driverless systemctl restart cups-browsed
- Check the existence of the queue and its options with
lpstat -t and lpoptions -p <queue_name> -l
The device-uri should begin ipp://.... The queue name is got from lpstat -t.
- The queue persists provided the printer is switched on and cups-browsed is running.
With the CreateIPPPrinterQueues directive cups-browsed sets up a queue for a remote printer. With NewIPPPrinterQueuesShared Yes in /etc/cups/cups-browsed uncommented the printer is shared with other machines on the local network.
cups-browsed supports also a kind of legacy driverless printing. This means that some other common PDLs such as PostScript, PCL-XL, and PCL 5c/e are supported and also older IPP versions (1.x). Note that missing capability information can be replaced with default values and that implementations of these languages in the printers are often not reliable, so that, in contrast to official driverless printing, printing often does not work perfectly. Note that the PCL of HP inkjets does not work and therefore cups-browsed does not auto-create queues for this PDL.
CUPS 2.2.4 and Driverless Printing
CUPS' ability directly to browse the DNS-SD (Bonjour) broadcasts of remote print queues and printers, previously absent, was introduced in CUPS 2.2.4. This means that a system with CUPS 2.2.4 or later (such as Debian 10.x.x) will display remote queues and printers with lpstat -e and in the print dialogs of some applications without cups-browsed (needed on Debian 8.x.x and Debian 9.x.x for remote queue management) being on the system. No action on the part of the user is required.
Essentially, CUPS uses its CupsGetDests and CupsEnumDests functions to discover shared queues and printers which can be printed to on the local network and makes them available for display in an application. Whether or not the application displays them depends on the chosen application. Printing to an enumerated entry leads to the formation of a temporary queue.
lpstat -a only shows queues of the local CUPS daemon and not DNS-SD advertised queues or printers. lpstat -e and lpstat -l -e additionally enumerate queues and printers which can be accessed on the network.
- The Qt print dialog of applications like Okular enumerate remote, shared queues and printers and uses a temporary queue for printing.
- The Libreoffice print dialog behaves the same way as the Qt dialog.
- The print dialog of GTK applications such as Firefox and Evince does not function in the same way as the Qt and Libreoffice dialogs. It obtains queue and printer information directly from DNS-SD broadcasts and not through CUPS, so it has no knowledge of what CUPS 2.2.4 and later are capable of doing.
Let us consider the behaviour of the GTK print dialog in a little more detail. The applications using it produce a PDF with libcairo2. A Debian CUPS server will have no trouble accepting and printing this PDF when it is sent to a remote queue listed in the dialog. If the entry is a remote printer, the printer has to be able to accept and process the PDF. This might not be the case, so the dialog will display
print <Location> Rejecting Jobs
A check with avahi-browse might reveal for the printer:
showing that PDF is not an accepted Page Description Language.
The solution is to put cups-browsed on the system and, in cups-browsed.conf, have cups-browsed create permanent, local queues (rather than the CUPS temporary queues) for remote queues and printers with
It very likely that only the entry for the remote printer is wanted, so alter cups-browsed.conf to have
Note that managing queues and printers in the GTK dialog in this way also leads to other dialogs and the command line utilities following suit.
CUPS and Driverless Printing: Miscellaneous
AirPrint and IPP Everywhere printers generally have a web interface for administration. It is accessed in a web browser with
http://<IP_address or host name of the printer>
The hostname can be obtained from the output of avahi-browse (see below). Make sure that IPP support and Bonjour broadcasting are enabled. The configuration options will probably be accessed under a Networking link and it could be that activating AirPrint is sufficient to activate both services.
A PPD auto-generated for a queue created by cups-browsed, the web interface and system-config-printer gives the highest priority to PDF, followed by PWG raster and then Apple raster. The priority sequence continues with PCL-XL, PostScript and finally PCL 5c/e. A PPD auto-generated for a queue created by lpadmin behaves slightly differently because it uses CUPS' PPD generator.
A text file sent to an AirPrint or IPP Everywhere printer would be filtered by CUPS and cups-filters to output an Apple or PWG raster file. If the printer has PDL support for MIME media type application/pdf a PDF would be sent instead. Typical possibilities for the filter chain are:
->|--------------------------------------------> Printer text -> texttopdf -> pdftopdf -> PDF ->| gstoraster -> rastertopwg -> PWG raster ---> Printer ->| gstoraster -> rastertopwg -> Apple raster -> Printer
avahi-browse -art | less
Identify your Bonjour-advertised IPP printer and look for entries beginning URF=... and pdl=... . If URF=... exists and pdl=... contains image/urf you have an AirPrint printer.
For an HP Envy 4502:
For a Brother MFC-J650DW:
URF = SRGB24,W8,CP1,IS1,MT1-8-11,OB9,PQ4-5,RS300,OFU0,V1.2,DM3 pdl = application/octet-stream,application/vnd.brother-hbp,image/pwg-raster,image/urf,image/jpeg
The pdl contains an additional image/pwg-raster. This printer will accept and print PWG raster files. It could be an IPP Everywhere printer, but that all depends on whether it fulfills all the criteria necessary for the manufacturer to self-certify it with the Printer Working Group (PWG). However, it is possible the printer IPP implementation is sufficient for driverless printing to be used with CUPS.
The pdl=... line for the Envy 4502 above contains PCLm. This has nothing to do with PCL 5c/e and PCL-XL but is a streaming PDF-based, raster protocol (Printer Control Lanaguage-Mobile). It is mandated by the Wi-Fi Direct standard. Since version 1.17.0 of cups-filters application/PCLm it has been a supported MIME media type via the rastertopclm filter. CUPS itself will never support PCLm.
Currently, driverless printing with CUPS is network-only as it requires IPP for querying the capabilities from the printer so that the PPD can be generated. It also needs IPP to send option settings to the printer (as IPP attributes). More investigation and testing is needed on IPP over USB to make driverless printing also work via USB.
Driverless printing usually allows only adjustments on printing as they are thought out by the printer manufacturers. A printer driver like Gutenprint allows a lot fine tuning that goes far beyond a manufacturer's possibilities. This driver may suit photo enthusiasts more than a driverless solution.
Purchasing a printer with Apple raster and/or PWG raster capability means looking at the box containing the printer and printer brochures and manuals. AirPrint has been going for some time so it is usually fairly prominent as a feature in the literature. IPP Everywhere is much newer and may not be advertised. However, PWG raster could be on a ?GCP-enabled (GCP Ready) printer. If PDF is not a PDL for the printer it is obliged to have PWG raster. With PDF as a language it might have PWG raster as a fallback PDL.
Didier 'OdyX' Raboud <email@example.com> for guiding and supporting CUPS 2.2.2, cups-filters and cups-browsed through the experimental archive and into unstable. Till Kamppeter <firstname.lastname@example.org> for his integration of cups-filters and cups-browsed with CUPS 2.2.2. Michael R. Sweet <email@example.com> for developing the rastertopwg filter to support Apple raster.