Differences between revisions 1 and 18 (spanning 17 versions)
Revision 1 as of 2017-01-19 14:34:47
Size: 21297
Editor: Brian Potkin
Comment: Initial release
Revision 18 as of 2019-09-14 19:30:48
Size: 30622
Editor: nodiscc
Comment: standardize page names
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from DriverlessPrinting
Line 3: Line 4:
----Driverless printing with CUPS and Google Cloud Print. ----Driverless printing with CUPS. Requires at least CUPS 2.2.2 and version 1.13.0 of cups-filters. Debian 10 (buster) and later installations meet both these conditions. The [[QuickPrintQueuesCUPS|advice here]] could get your modern IPP printer going with little effort.
Line 10: Line 11:
=== IMPORTANT NOTE ===

Driverless printing with CUPS requires at least CUPS 2.2.2 and version 1.13.0 of cups-filters. On 19.01.17 the packages are available only in the [[DebianExperimental|experimental distribution]].

Line 19: Line 15:
There is a variety of methods for a client to submit a job to a driverless printing system:
There exist a variety of methods for a client to submit a job to a printing system and print driverlessly:

 * Print [[#lpadmin|directly from an application]] on the client.

 * Use [[AirPrint|AirPrint]] or [[IPPEverywhere|IPP Everywhere]] printing.

 * Use a cloud service such as [[GoogleCloudPrint|Google Cloud Print (GCP)]].

 * Send the job as an email attachment to a special address.
 
Line 23: Line 27:
 * Print [[#lpadmin|directly from an application]] on the client.

 * Send the job as an email attachment to a special address.

 * Use [[AirPrint|AirPrint]] or [[IPPEverywhere|IPP Everywhere]] printing.

 * Use a cloud service such as [[#gcp|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.
This page is intended to highlight and explain driverless printing in the context of directly communicating with a printer 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.

Remember that CUPS can act as a client or server.
In its server capacity it can emulate an [[IPPEverywhere|IPP Everywhere]] or [[AirPrint|Apple AirPrint]] printer.
However, the focus here is on CUPS as a client connecting to a printer which offers [[#driverless|driverless printing functions]].
Line 36: Line 37:
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 [[PrintQueuesCUPS#ppd|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 which 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 which is encountered. This requires a level of expertise and a time and effort commitment which cannot be assumed to be possessed.
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 [[PrintQueuesCUPS#ppd|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 ([[PrintingGlossaryandIndex#pdlan|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, especially 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 laptop computer or 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.

Then contrast the printer situation
with the behaviour of other peripherals like keyboards, mice, cameras and USB mass storage.
Plug such devices in and they are immediately and reliably there to be used.
The objective is to have printing no less available when a printer is detected.
Line 42: Line 52:
 * 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) which the client can send and which 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 [[#pdls|Apple raster, PWG raster]] or PDF 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.
 * The printer advertises its presence and capabilities with mDNS/DNS-SD ([[PrintingGlossaryandIndex#dnssd|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 [[PrintingGlossaryandIndex#ipp|IPP]] protocol. This is the ''transport'' protocol; it can obtain capability information from the selected printer and transport data to it.

 * There is a common [[PrintingGlossaryandIndex#pdl|PDL]] 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 [[#pdls|Apple raster, PWG raster]], PDF or [[#misc|PCLm]] as a PDL.

Note again that we are talking here about sending a job directly to a printer, not to a print queue being advertised by CUPS.
Line 55: Line 65:
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 which which 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.
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.
Line 60: Line 72:
 * PWG raster is a more recent raster format, devised to be used with [[IPPEverywhere|IPP Everywhere]] printers. It is based on [[https://www.cups.org/doc/spec-raster.html|CUPS raster]] and is [[https://ftp.pwg.org/pub/pwg/candidates/cs-ippraster10-20120420-5102.4.pdf|well-documented]]. The MIME media type is image/pwg-raster.  * PWG raster is a more recent raster format, devised to be used with [[IPPEverywhere|IPP Everywhere]] printers. It is based on [[https://www.cups.org/doc/spec-raster.html|CUPS raster]] and is [[https://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf|well-documented]]. The MIME media type is image/pwg-raster.
Line 65: Line 77:
The abilitity to create Apple raster files has been added to the existing PWG raster support in CUPS and made its appearence in [[DebianList:debian-printing/2017/01/msg00029.html|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 [[https://lists.linuxfoundation.org/pipermail/printing-architecture/2016/003381.html|joined the class of printers]] which will work driverless with Debian. The abilitity to create Apple raster files has been added to the existing [[IPPEverywhere|PWG raster support]] in CUPS and made its appearence in [[DebianList:debian-printing/2017/01/msg00029.html|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 [[https://lists.linuxfoundation.org/pipermail/printing-architecture/2016/003381.html|joined the class of printers]] that will work driverless with Debian.
Line 71: Line 84:
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 possibilty of avoiding the use of non-free drivers on the server used for printing. 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 [[PrintQueuesCUPS#avoiding|avoiding the use of non-free drivers]] on the CUPS client or server used for printing.

<<Anchor(generator1)>>
=== The CUPS PPD Generator ===

To fully support driverless printing, CUPS has a PPD generator that will drive a traditional CUPS print queue.
The generator queries the printer and creates the necessary PPD options and values needed to support Apple Raster, PWG Raster, JPEG, and PDF printing.
A CUPS generated PPD uses the [[DebianMan:lpadmin|everywhere model]] and can be identified from the ''*PCFileName "ippeve.ppd"'' line in the PPD.

 * The application calls the filter required to convert the print file to the printer supported PDL.

 * The filter reads the auto-generated PPD and converts to the required format.

 * The print job is submitted to the printer with the converted data produced from the filter.

 * If a PDF or JPEG file is being printed, it can be sent to the printer without any filtering; this is accounted for in the *cupsFilter2 lines that are added to the generated PPD.

 * 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 because a PDF is given the highest priority. Typical possibilities for the filter chain are:

{{{
                                     ->|--------------------------------------------> Printer
text -> texttopdf -> pdftopdf -> PDF ->| gstoraster -> rastertopwg -> PWG raster ---> Printer
                                     ->| gstoraster -> rastertopwg -> Apple raster -> Printer
}}}

<<Anchor(generator2)>>
=== The cups-filters PPD Generator ===

This generator uses the DebianMan:driverless utility and is basically a copy of the [[#generator1|PPD generator from CUPS]] that has been put into the DebPkg:libcupsfilters library.
It is kept in sync with the original by incorporating any changes to the original.
A libcupsfilters generated PPD can be identified from the ''*PCFileName "drvless.ppd"'' line in the PPD.

 * The cups-filters PPD generator is used by default with [[#cupsbrowsed|cups-browsed]] when a local print queue is auto-created for an IPP network printer.

 * It may also be used as an alternative to the CUPS PPD generator when a queue is set up with [[#lpadmin|lpadmin]], [[#scp|system-config-printer]] or the [[#webinterface|CUPS web interface]].

Although the cups-filters PPD generator is kept closely in step with the CUPS one, the two are not identical:

 * The original PPD generator only supports PWG Raster, Apple Raster, PDF, and JPEG as printer PDLs. The cups-filters PPD generator also accepts (with lower priority) !PostScript, PCL-XL, and PCL 5c/e for legacy printers.

 * The original PPD generator requires all printer capability, option, and choice information from the printer attributes IPP request. The cups-filters generator can, in some cases, fall back to using information from the Bonjour record or even hard-coded default values. This adds support for some legacy printers.

 * The cups-filters PPD generator is more flexible when it comes to adding support for PDLs. For example, consider PCLm: PCLm has nothing to do with PCL 5c/e and PCL-XL but is a [[https://www.google.com/patents/US20130100486|streaming PDF-based, raster protocol]] (''Printer Control Lanaguage-Mobile''). It is mandated by the [[https://www.wi-fi.org/discover-wi-fi/wi-fi-direct|Wi-Fi Direct]] standard. Since version 1.17.0 of cups-filters, ''application/PCLm'' has been a supported MIME media type via the ''rastertopclm'' filter. CUPS itself will [[https://github.com/apple/cups/issues/5095|never support PCLm]].

{{{
text -> texttopdf -> pdftopdf -> PDF ->| gstoraster -> rastertopclm -> PCLm ---> Printer
}}}

 * cups-filters has a policy of supporting new driverless printing technologies (see above), so its PPD generator is quite likely to accomodate developments.

 * Printers have bugs in their implementation of IPP. It is more likely that the cups-filters PPD generator will [[https://github.com/apple/cups/issues/5088|produce a fix]] than the CUPS version of the generator.

<<Anchor(shortlpadmin)>>
=== Creating a Driverless Print Queue with lpadmin (Short Version) ===

The URI of a printer:

{{{
driverless
}}}

The print queue (uses the [[#generator1|CUPS PPD generator]]):

{{{
lpadmin -p <print_queue_name> -v <URI> -E -m everywhere
}}}
Line 78: Line 158:
With a single !AirPrint printer on the network a partial output from ''lpinfo -v'' could be: With a single !AirPrint printer on the network a partial output from ```lpinfo -v``` could be:
Line 86: Line 166:
There are three ''device-uris'' for the printer. The ENVY 4500 has been
discovered from the printer's Bonjour broadcasts using the [[PrintQueuesCUPS#dnssd|dnssd://...]] backend. The ''snmp'' backend has also found the printer will accept jobs on [[PrintQueuesCUPS#networkuri|port 9100]] (''socket://192...''). Queues using either of these two device-uris would need to be set up with a PPD specified with the ''-m'' or ''-P'' option of lpadmin so would not be driverless. The URI for driverless printing is ''ipp://envy4500...''.

The device-uri for the printer can also be found with either of the [[DebianMan:ippfind|ippfind]] or [[DebianMan:driverless| driverless]] utilities.
The ''snmp'' backend has found the printer will accept jobs on [[PrintQueuesCUPS#networkuri|port 9100]] (''socket://192...'').
CUPS will not set up an [[#generator1|everywhere]] queue using this URI because it is unable to query the printer with it.

The ENVY 4500 has also been discovered from the printer's [[PrintingGlossaryandIndex#dnssd|Bonjour]] broadcasts using the [[PrintQueuesCUPS#dnssd|dnssd]] and [[PrintQueuesCUPS#networkuri|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.

The device-uri for the printer can also be found with the DebianMan:ippfind or DebianMan:driverless utilities.
`ippfind` locates DNS-SD advertised printers and queues.
`driverless` (a cups-filters utility) lists IPP printers only.
Line 98: Line 183:
driverless device-uri   (Generate a PPD for the printer at device-uri). driverless <device-uri> (Generate a PPD for the printer at <device-uri>).
Line 107: Line 192:
The ''everywhere'' directive will cause the printer referred to by the ''-v'' option to be queried. A list of printer capabilities is returned and a PPD is automatically generated for use by command line programs and applications. The [[DebianMan:lpadmin|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.

It might be preferred to have the PPD generated by cups-filters, so first find the ''driver URI'' (''driverless:ipp://...'') with

{{{
driverless list
}}}

and create the queue with

{{{
lpadmin -p <print_queue_name> -v <device-uri> -E -m <driver URI>
}}}

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 [[PrintQueuesCUPS#tempq|temporary queue]] on a client.
Line 114: Line 215:
 * 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 which contains the word ''driverless'' and move on to ''Continue''.
 * Open the web interface and choose ''Administration''. Select ''Add Printer''.

 * 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''.
Line 120: Line 221:
 * ''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.  * Under ''Model'' there should be options of ''IPP Everywhere'' and ''driverless''. The first option uses the [[#generator1|CUPS PPD generator]] and the second [[#generator2|that of cups-filters]]. Select and activate ''Add Printer''.

 * The ''IPP Everywhere'' choice creates a destination using CUPS' [[#tempq|temporary queue formation mechanism]]. Consequently, no default PPD options are on offer because the PPD is not created until printing to the destination takes place from the command line or an application. Printer options can, of course, be found [[#shorttempq|from the command line]] and from a print dialog within an application.
Line 129: Line 232:
 * 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.
 * Highlight the printer entry and choose the ''Driverless IPP'' entry.

 * Moving on has system-config-printer searching for a driver, auto-generating a PPD with the [[#generator2|cups-filters generator]] and offering a screen to describe the printer. Choose ''Apply'' when done.

 * system-config-printer [[https://github.com/zdohnal/system-config-printer/issues/125|cannot use]] the [[#generator1|CUPS PPD generator]].

<<Anchor(shortcupsbrowsed)>>
=== Creating a Driverless Print Queue with cups-browsed (Short Version) ===

Edit ''/etc/cups/cups-browsed.conf'' to uncomment the directive below:

{{{
CreateIPPPrinterQueues all
}}}

Restart:

{{{
systemctl restart cups-browsed
}}}
Line 138: Line 256:
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. This method leads to a fully automatic discovery of an !AirPrint or IPP Everywhere printer and sets up a print queue, creating a PPD for it with the [[#generator1|CUPS PPD generator]].
The [[#generator2|cups-filters PPD generator]] may be used instead; see the ''UseCUPSGeneratedPPDs'' directive in the [[DebianMan:cups-browsed.conf]] manual.
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.
Line 158: Line 279:
 * The device-uri should begin ''ipp://...''.
 *
The queue name is got from ''lpstat -t''.
 * The device-uri should begin ''ipp://...''. The queue name is got from ''lpstat -t''.
Line 162: Line 282:
 * 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 [[#generator1|official]] driverless printing, printing often does not work perfectly. Note that the PCL of HP inkjets does not work and therefore cups-browsed [[DebianList:debian-printing/2016/03/msg00144.html|does not auto-create]] queues for this PDL.

<<Anchor(shortippusbxd)>>
=== IPP-over-USB (Short Version) ===

 * Install DebPkg:ippusbxd.
 * Expose printer on [[#choice|dummy0 or localhost]].
 * Install systemd service file.
 * Plug switched-on printer into a USB port.

<<Anchor(ippusbxd)>>
=== IPP-over-USB ===

The previous methods to set up driverless printing with CUPS are network-only.
They require IPP for querying the capabilities from the printer so that the PPD can be generated.
They also need IPP to send option settings to the printer (as IPP attributes).
Fortunately, driverless printing is not confined to the network only but also works in this way via USB using DebianMan:ippusbxd.
A recent AirPrint printer [[https://lists.cups.org/pipermail/cups/2018-September/074272.html|should support]] IPP-over-USB.

Whether a printer can use IPP-over-USB can be determined by doing

{{{
lsusb -v | less
}}}

and searching for the line containing

 * bInterfaceClass.*7

A ''bInterfaceProtocol'' line should be found a few lines below this one.
A value of ''4'' indicates a USB IPP device.

The ''readme.md'' in ''/usr/share/doc/ippusbxd'' lays out the principles underlying the program's operation.
We will look at implementing these principles in the context of exposing a printer on a dummy0 interface on a Debian 10.x.x installation and with [[#cupsbrowsed|cups-browsed]] running.

Set up the dummy0 interface:

{{{
ip link add dummy0 type dummy # Load the dummy module and create a dummy interface.
ip link set dummy0 up multicast on # Bring the interface up.
ip addr add 192.168.7.80/24 dev dummy0 # Give the interface an unused address.
}}}

Check the existence of the interface with

{{{
ip a
}}}

It is tedious to have to do this every time the computer is switched on, so a [[https://www.freedesktop.org/software/systemd/man/systemd.service.html|systemd service]] is indicated.

Create the file ''/usr/local/sbin/create-dummy0'':

{{{
#!/bin/bash
#!/bin/bash

IP=$(ip a | grep dummy0)

if [ -z "$IP" ]
then
        ip link add dummy0 type dummy
        ip link set dummy0 up multicast on
        ip addr add 192.168.7.222/24 dev dummy0
else rmmod dummy
fi
}}}

Now create ''/lib/systemd/system/dummy0.service'':

{{{
[Unit]
Description=Create a dummy interface for ippusbxd

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/create-dummy0
ExecStop=/usr/local/sbin/create-dummy0

[Install]
WantedBy=multi-user.target
}}}

Then:

{{{
systemctl daemon-reload
}}}

The dummy0 service will be started when the machine is booted.
Thereafter, control whether it is operative with

{{{
systemctl stop dummy0.service
systemctl start dummy0.service
}}}

Having exposed the printer on the dummy0 interface it should be sufficient to connect a suitable printer to a computer, switch it on and issue the command

{{{
ippusbxd -i dummy0
}}}

to have a PPD generated by cups-browsed and a [[#tempq|permanent queue]] for the printer created.
Check with

{{{
ls -l /etc/cups/ppd
lpstat -a
ipstat -l -e
}}}

The ippusbxd daemon is stopped and the print queue removed when the printer is turned off or disconnected from its USB cable.

{{{#!wiki note
Versions of cups-browsed greater than 1.14.0 have ''!LocalOnly'' as the default value of ''CreateIPPPrinterQueues''.
Consequently, no adjustments are needed to ''/etc/cups/cups-browsed.conf'' to have the printer visible locally.
See the cups-browsed [[https://github.com/OpenPrinting/cups-filters/blob/master/NEWS|changelog]] for the rationale.
}}}

Starting and stopping ippusbxd automatically to create and delete a print queue (rather than using the command line) becomes possible using the ippusbxd-provided systemd service file:

{{{
cp /usr/share/doc/ippusbxd/examples/ippusbxd@.service.dummy0 /lib/systemd/system/ippusbxd@.service
systemctl daemon-reload
}}}

Power-on and power-off the printer (or attach or detach its USB cable) to have this auto-creation of a queue.
Share the queue on the local network using the [[PrintQueuesCUPS#webinterface|CUPS web interface]] or do

{{{
cupsctl --share-printers
lpadmin <queue_name> -o printer-is-shared=true
}}}

<<Anchor(choice)>>
{{{#!wiki note
You are free, of course, to [[https://lists.debian.org/debian-printing/2018/09/msg00129.html|follow upstream's advice]] and expose the printer on the localhost interface.
But, until [[DebianBug:909564|bug #909564]] is resolved, you will have to patch avahi yourself.

Note also that the scanning function of an [[PrintingGlossaryandIndex#mfd|MFD]] becomes [[https://lists.debian.org/debian-printing/2019/02/msg00014.html|unavailable]] when IPP-over-USB is used.
}}}

<<Anchor(shorttempq)>>
=== CUPS 2.2.4 and Driverless Printing (Short Version) ===

Without cups-browsed running.

Display local and remote queues and remote IPP printers:

{{{
lpstat -e
lpstat -l -e
}}}

Query printer options:

{{{
lpoptions -p <destination>
lpoptions -p <destination> -l
}}}


Print:

{{{
lp -d <queue_or_printer> -o [option] <file>
}}}


<<Anchor(tempq)>>
=== 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 IPP 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 IPP 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` shows only 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 DebPkg:okular and DebPkg:qpdfview enumerates remote, shared queues and printers and uses a temporary queue for printing.
 * The DebPkg:libreoffice print dialog behaves the same way as the Qt dialog.

 * the GTK print dialog [[#gtk|has its own way]] of dealing with a network printer.


<<Anchor(gtk)>>
=== CUPS 2.2.4 and the GTK Print Dialog ===

The print dialog of GTK applications such as DebPkg:firefox and DebPkg:evince does not function in the same way as the [[#tempq|Qt and Libreoffice dialogs]].
It obtains queue and printer information directly from [[PrintingGlossaryandIndex#dnssd|DNS-SD]] broadcasts and not through CUPS, so it has no knowledge of what CUPS 2.2.4 and later are capable of doing.
This leads to the following problem.

 * Although the GTK dialog is aware of IPP printers on the local network via DNS-SD, it [[DebianBug:916267|does not support printing to them]] and will [[PrintQueuesCUPS#networkuri|possibly display]] a destination ''print'' and ''Rejecting Jobs'' for an IPP printer.

 * One solution is to check that [[#cupsbrowsed|cups-browsed]] is on the system and, in [[DebianMan:cups-browsed.conf|cups-browsed.conf]], have cups-browsed create permanent, local queues for remote queues and printers (rather than the CUPS [[#tempq|temporary queues]] which Qt applications and !LibreOffice use). This technique is [[#cupsbrowsed|described above]].

 * Because the GTK dialog might already show local queues and remote queues on CUPS servers it is likely that, with this first solution, only the additional entry for the remote printer is wanted. So alter ''cups-browsed.conf'' to have

{{{
CreateRemoteCUPSPrinterQueues No
}}}

 * A second solution is to create a permanent local queue for the printer with [[#lpadmin|lpadmin]], the [[#webinterface|CUPS web interface]] or [[#scp|system-config-printer]].

{{{#!wiki note
Managing queues and printers in the GTK dialog with the first solution also leads to the other dialogs adopting cups-browsed as the queue and printer management application.
}}}
Line 166: Line 497:

* !AirPrint and IPP Everywhere printers generally have a web interface for administration. It is accessed in a web browser with
 * !AirPrint and IPP Everywhere printers generally have a [[PrintingGlossaryandIndex#ews|web interface]] for administration. It is accessed in a web browser with
Line 173: Line 503:
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, then PWG raster and finally Apple raster. A PPD auto-generated for a queue created by lpadmin [[https://github.com/apple/cups/issues/4932|behaves slightly differently]] because it [[DebianBug:851499|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
}}}
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.
Line 191: Line 513:
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. 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.
Line 207: Line 530:
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 [[http://ftp.pwg.org/pub/pwg/candidates/cs-ippeveselfcert10-20160219-5100.20.pdf|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.

 * 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 [[DebianPkg:ippusbxd|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 [[DebianPkg:printer-driver-gutenprint|Gutenprint]] allows a lot fine tuning which 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.

<<Anchor(gcp)>>
=== Google Cloud Print (GCP) and CUPS ===

The conditions for setting up and using GCP with CUPS are

 * A Google account with print queues added to the account.

 * A ''connector'' between the cloud and the CUPS print queues.

{{{#!wiki note
We will be dealing in the remaining sections of this page with adding only CUPS print queues (not cloud-enabled printers) to the Google account.
}}}

A ''connector'' (or ''proxy'') maintains a connection between GCP and the server running cupsd. A persistent WikiPedia:XMPP channel is established over port 5222 or port 443 to talk.google.com. Messages over this channel can inform GCP about changes to the CUPS print queues and GCP can notify the server when there is a job submitted to it from a client. The job can then be downloaded and printed. Remember that this client can be anywhere in the world and must have the credentials to authenticate to the Google account or permission to use the printers it offers.

A user registers the print queue with GCP and claims the printer by providing a registration token from Google in an authenticated request to a specified URL via a browser. GCP responds with the credentials necessary for printing to take place. Added print queues can be shared by following the instructions
[[https://support.google.com/cloudprint/answer/2541899?hl=en&ref_topic=4456286|here]].

{{{#!wiki note
Note that GCP will not register a CUPS print queue which does not have a
PPD associated with it because no printer capabilities can be found. A
connector will see such a queue as invalid and refuse to add it to the
Google account.
}}}

On receiving notification of a pending job the connector downloads the document and submits it to the printing system. The MIME media type of the file will be application/pdf.

Debian provides connectors with

 * The [[DebianPkg:chromium|Chromium web browser]]

 * [[DebianPkg:cloudprint|cloudprint]]

 * [[DebianPkg:google-cloud-print-connector|google-cloud-print-connector]]

Closing down a connector results in added queues becoming offline.

<<Anchor(chromium)>>
=== The Chromium Web Browser ===

From ''customize and control'' in Chromium's interface:

 * Settings.
 * Show advanced settings.
 * Google Cloud Print/Manage.
 * Classic printers/Add printers.
 * Select printers to register and add them to the account.
 * Manage your printers.

<<Anchor(cloudprint)>>
=== cloudprint ===

Install the cloudprint package and, as a user, do

{{{
cloudprint -d
}}}

to daemonise the service, or

{{{
cloudprint &
}}}

to have it run in the background.

You will be given a URL to go to and the program will output ''trying for the win'' while it waits for you to claim the print queues and complete their registration.

{{{
Go to https://goo.gl/printer/7hhnd to claim this printer
trying for the win
trying for the win
trying for the win
Printer claimed by a_debian_user@gmail.com.
Polling for jobs on HP-ENVY-4500-series
Polling for jobs on LaserJet-300
Polling for jobs on DotMatrix
Establishing connection to xmpp server talk.google.com:5223
xmpp connection established
}}}

 * The file .cloudprintauth.json will be created for account authententication credentials in the home directory.
 * The default is to include all [[#gcp|valid print queues]] known to CUPS.
 * Log into the Google account and then go to either the [[https://www.google.com/cloudprint#printers|printer management]] or [[https://www.google.com/cloudprint/gadget.html|print gadget]] page to display the queues known to GCP.

Delete queues from the default set with

{{{
cloudprint -x HP -x Dot
}}}

cloudprint does not recognise when the creation or deletion of a CUPS
queue takes place on the server so the event is not communicated to
GCP. Include a newly created queue, wf2530, with

{{{
cloudprint -i wf -i HP -i Dot -i Las
}}}

Automatic registration of selected queues when cloudprint is started can
be accomplished from a ''.cloudprint.conf'' file in the home directory:

{{{
include = [Las, DotMatrixT] # Excludes all other queues.
# exclude = [HP, Las] # Includes all other queues.
}}}

 * The [[DebianPkg:cloudprint-service|cloudprint-service]] package provides a systemd service file if there is a preference for controlling cloudprint from the init system.

<<Anchor(gcpc)>>
=== google-cloud-print-connector ===

Install google-cloud-print-connector. There are two programs, gcp-cups-connector-util and gcp-cups-connector, in the package.

gcp-cups-connector-util contains options for utility tools to create a
configuration file, delete all print queues associated with the particular connector instance and manage print jobs. See all options with

{{{
gcp-cups-connector-util -h
}}}

To produce a configuration file, gcp-cups-connector.config.json, in your
home directory do

{{{
gcp-cups-connector-util init
}}}

Then start the connector in the foreground or background with

{{{
gcp-cups-connector
gcp-cups-connector &
}}}

 * Logging by gcp-cups-connector is done to ''/tmp/cups-connector''.
 * Default queue registration is the same as with [[#cloudprint|cloudprint]].
 * The [[https://www.google.com/cloudprint/#printers|printer management web interface]] is used for deleting unwanted queues.
 * gcp-cups-connector will notice if queues are added or deleted on the CUPS server and automatically update GCP with the new information.

=== Acknowedgements ===

<<MailTo(odyx@debian.org,Didier "Odyx" Ramboud)>> for guiding and supporting CUPS 2.2.2, cups-filters and cups-browsed through the experimental archive and into unstable. <<MailTo(till.kamppeter@gmail.com,Till Kamppeter)>> for his integration of cups-filters and cups-browsed with CUPS 2.2.2. <<MailTo(msweet@apple.com,Michael R. Sweet)>> for developing the rastertopwg filter to support Apple raster.
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 [[http://ftp.pwg.org/pub/pwg/candidates/cs-ippeveselfcert10-20160219-5100.20.pdf|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.

 * Driverless printing usually allows only adjustments on printing as they are thought out by the printer manufacturers. A printer driver like [[DebianPkg:printer-driver-gutenprint|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 [[GoogleCloudPrint|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.

=== Acknowledgements ===

<<MailTo(odyx@debian.org,Didier 'OdyX' Raboud)>> for guiding and supporting CUPS 2.2.2, cups-filters and cups-browsed through the experimental archive and into unstable.
<<MailTo(till.kamppeter@gmail.com,Till Kamppeter)>> for his integration of cups-filters and cups-browsed with CUPS 2.2.2.
<<MailTo(msweet@apple.com,Michael R. Sweet)>> for developing the rastertopwg filter to support Apple raster.
Line 372: Line 558:
## If this page belongs to an existing Category, add it below.
## CategorySomething | CategoryAnother

CategoryPrinter

Translation(s): none


Driverless printing with CUPS. Requires at least CUPS 2.2.2 and version 1.13.0 of cups-filters. Debian 10 (buster) and later installations meet both these conditions. The advice here could get your modern IPP printer going with little effort.

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 exist a variety of methods for a client to submit a job to a printing system and print driverlessly:

  • Print directly from an application on the client.

  • Use AirPrint or IPP Everywhere printing.

  • Use a cloud service such as ?Google Cloud Print (GCP).

  • Send the job as an email attachment to a special address.
  • Web print. The document is uploaded from a web browser via a web form style interface.

This page is intended to highlight and explain driverless printing in the context of directly communicating with a printer 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.

Remember that CUPS can act as a client or server. In its server capacity it can emulate an IPP Everywhere or Apple AirPrint printer. However, the focus here is on CUPS as a client connecting to a printer which offers driverless printing functions.

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, especially 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 laptop computer or 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.

Then contrast the printer situation with the behaviour of other peripherals like keyboards, mice, cameras and USB mass storage. Plug such devices in and they are immediately and reliably there to be used. The objective is to have printing no less available when a printer is detected.

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

  • There is a common PDL 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 again 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.

  • PWG raster is a more recent raster format, devised to be used with IPP Everywhere printers. It is based on CUPS raster and is well-documented. The MIME media type is image/pwg-raster.

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 CUPS client or server used for printing.

The CUPS PPD Generator

To fully support driverless printing, CUPS has a PPD generator that will drive a traditional CUPS print queue. The generator queries the printer and creates the necessary PPD options and values needed to support Apple Raster, PWG Raster, JPEG, and PDF printing. A CUPS generated PPD uses the everywhere model and can be identified from the *PCFileName "ippeve.ppd" line in the PPD.

  • The application calls the filter required to convert the print file to the printer supported PDL.
  • The filter reads the auto-generated PPD and converts to the required format.
  • The print job is submitted to the printer with the converted data produced from the filter.
  • If a PDF or JPEG file is being printed, it can be sent to the printer without any filtering; this is accounted for in the *cupsFilter2 lines that are added to the generated PPD.
  • 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 because a PDF is given the highest priority. Typical possibilities for the filter chain are:

                                     ->|--------------------------------------------> Printer
text -> texttopdf -> pdftopdf -> PDF ->| gstoraster -> rastertopwg -> PWG raster ---> Printer
                                     ->| gstoraster -> rastertopwg -> Apple raster -> Printer

The cups-filters PPD Generator

This generator uses the driverless utility and is basically a copy of the PPD generator from CUPS that has been put into the libcupsfilters library. It is kept in sync with the original by incorporating any changes to the original. A libcupsfilters generated PPD can be identified from the *PCFileName "drvless.ppd" line in the PPD.

Although the cups-filters PPD generator is kept closely in step with the CUPS one, the two are not identical:

  • The original PPD generator only supports PWG Raster, Apple Raster, PDF, and JPEG as printer PDLs. The cups-filters PPD generator also accepts (with lower priority) PostScript, PCL-XL, and PCL 5c/e for legacy printers.

  • The original PPD generator requires all printer capability, option, and choice information from the printer attributes IPP request. The cups-filters generator can, in some cases, fall back to using information from the Bonjour record or even hard-coded default values. This adds support for some legacy printers.
  • The cups-filters PPD generator is more flexible when it comes to adding support for PDLs. For example, consider PCLm: PCLm 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 has been a supported MIME media type via the rastertopclm filter. CUPS itself will never support PCLm.

text -> texttopdf -> pdftopdf -> PDF ->| gstoraster -> rastertopclm -> PCLm ---> Printer
  • cups-filters has a policy of supporting new driverless printing technologies (see above), so its PPD generator is quite likely to accomodate developments.
  • Printers have bugs in their implementation of IPP. It is more likely that the cups-filters PPD generator will produce a fix than the CUPS version of the generator.

Creating a Driverless Print Queue with lpadmin (Short Version)

The URI of a printer:

driverless

The print queue (uses the CUPS PPD generator):

lpadmin -p <print_queue_name> -v <URI> -E -m everywhere

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...). CUPS will not set up an everywhere queue using this URI because it is unable to query the printer with it.

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.

The device-uri for the printer can also be found with the ippfind or driverless utilities. ippfind locates DNS-SD advertised printers and queues. driverless (a cups-filters utility) lists IPP printers only.

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.

It might be preferred to have the PPD generated by cups-filters, so first find the driver URI (driverless:ipp://...) with

driverless list

and create the queue with

lpadmin -p <print_queue_name> -v <device-uri> -E -m <driver URI>

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.

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

  • Under Model there should be options of IPP Everywhere and driverless. The first option uses the CUPS PPD generator and the second that of cups-filters. Select and activate Add Printer.

  • The IPP Everywhere choice creates a destination using CUPS' temporary queue formation mechanism. Consequently, no default PPD options are on offer because the PPD is not created until printing to the destination takes place from the command line or an application. Printer options can, of course, be found from the command line and from a print dialog within an application.

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.

  • Highlight the printer entry and choose the Driverless IPP entry.

  • Moving on has system-config-printer searching for a driver, auto-generating a PPD with the cups-filters generator and offering a screen to describe the printer. Choose Apply when done.

  • system-config-printer cannot use the CUPS PPD generator.

Creating a Driverless Print Queue with cups-browsed (Short Version)

Edit /etc/cups/cups-browsed.conf to uncomment the directive below:

CreateIPPPrinterQueues all

Restart:

systemctl restart cups-browsed

Creating a Driverless Print Queue with cups-browsed

This method leads to a fully automatic discovery of an AirPrint or IPP Everywhere printer and sets up a print queue, creating a PPD for it with the CUPS PPD generator. The cups-filters PPD generator may be used instead; see the UseCUPSGeneratedPPDs directive in the cups-browsed.conf manual. 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.

IPP-over-USB (Short Version)

IPP-over-USB

The previous methods to set up driverless printing with CUPS are network-only. They require IPP for querying the capabilities from the printer so that the PPD can be generated. They also need IPP to send option settings to the printer (as IPP attributes). Fortunately, driverless printing is not confined to the network only but also works in this way via USB using ippusbxd. A recent AirPrint printer should support IPP-over-USB.

Whether a printer can use IPP-over-USB can be determined by doing

lsusb -v | less

and searching for the line containing

  • bInterfaceClass.*7

A bInterfaceProtocol line should be found a few lines below this one. A value of 4 indicates a USB IPP device.

The readme.md in /usr/share/doc/ippusbxd lays out the principles underlying the program's operation. We will look at implementing these principles in the context of exposing a printer on a dummy0 interface on a Debian 10.x.x installation and with cups-browsed running.

Set up the dummy0 interface:

ip link add dummy0 type dummy          # Load the dummy module and create a dummy interface.
ip link set dummy0 up multicast on     # Bring the interface up.
ip addr add 192.168.7.80/24 dev dummy0 # Give the interface an unused address.

Check the existence of the interface with

ip a

It is tedious to have to do this every time the computer is switched on, so a systemd service is indicated.

Create the file /usr/local/sbin/create-dummy0:

#!/bin/bash

IP=$(ip a | grep dummy0)

if [ -z "$IP" ]
then
        ip link add dummy0 type dummy
        ip link set dummy0 up multicast on
        ip addr add 192.168.7.222/24 dev dummy0
else rmmod dummy
fi

Now create /lib/systemd/system/dummy0.service:

[Unit]
Description=Create a dummy interface for ippusbxd

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/create-dummy0
ExecStop=/usr/local/sbin/create-dummy0

[Install]
WantedBy=multi-user.target

Then:

systemctl daemon-reload

The dummy0 service will be started when the machine is booted. Thereafter, control whether it is operative with

systemctl stop dummy0.service
systemctl start dummy0.service

Having exposed the printer on the dummy0 interface it should be sufficient to connect a suitable printer to a computer, switch it on and issue the command

ippusbxd -i dummy0

to have a PPD generated by cups-browsed and a permanent queue for the printer created. Check with

ls -l /etc/cups/ppd
lpstat -a
ipstat -l -e

The ippusbxd daemon is stopped and the print queue removed when the printer is turned off or disconnected from its USB cable.

Versions of cups-browsed greater than 1.14.0 have LocalOnly as the default value of CreateIPPPrinterQueues. Consequently, no adjustments are needed to /etc/cups/cups-browsed.conf to have the printer visible locally. See the cups-browsed changelog for the rationale.

Starting and stopping ippusbxd automatically to create and delete a print queue (rather than using the command line) becomes possible using the ippusbxd-provided systemd service file:

cp /usr/share/doc/ippusbxd/examples/ippusbxd@.service.dummy0 /lib/systemd/system/ippusbxd@.service
systemctl daemon-reload

Power-on and power-off the printer (or attach or detach its USB cable) to have this auto-creation of a queue. Share the queue on the local network using the CUPS web interface or do

cupsctl --share-printers
lpadmin <queue_name> -o printer-is-shared=true

You are free, of course, to follow upstream's advice and expose the printer on the localhost interface. But, until bug #909564 is resolved, you will have to patch avahi yourself.

Note also that the scanning function of an MFD becomes unavailable when IPP-over-USB is used.

CUPS 2.2.4 and Driverless Printing (Short Version)

Without cups-browsed running.

Display local and remote queues and remote IPP printers:

lpstat -e
lpstat -l -e

Query printer options:

lpoptions -p <destination>
lpoptions -p <destination> -l

Print:

lp -d <queue_or_printer> -o [option] <file>

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 IPP 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 IPP 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 shows only 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 and qpdfview enumerates 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 GTK print dialog has its own way of dealing with a network printer.

CUPS 2.2.4 and the GTK Print 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. This leads to the following problem.

  • Although the GTK dialog is aware of IPP printers on the local network via DNS-SD, it does not support printing to them and will possibly display a destination print and Rejecting Jobs for an IPP printer.

  • One solution is to check that cups-browsed is on the system and, in cups-browsed.conf, have cups-browsed create permanent, local queues for remote queues and printers (rather than the CUPS temporary queues which Qt applications and LibreOffice use). This technique is described above.

  • Because the GTK dialog might already show local queues and remote queues on CUPS servers it is likely that, with this first solution, only the additional entry for the remote printer is wanted. So alter cups-browsed.conf to have

CreateRemoteCUPSPrinterQueues No

Managing queues and printers in the GTK dialog with the first solution also leads to the other dialogs adopting cups-browsed as the queue and printer management application.

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.

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:

URF=CP1,MT1-2-8-9-10-11,OB9,OFU0,PQ3-4-5,RS300-600,SRGB24,W8-16,DEVW8-16,DEVRGB24-48,ADOBERGB24-48,DM3,IS1,V1.3
pdl=application/vnd.hp-PCL,image/jpeg,application/PCLm,image/urf

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.

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

Acknowledgements

Didier 'OdyX' Raboud <odyx@debian.org> for guiding and supporting CUPS 2.2.2, cups-filters and cups-browsed through the experimental archive and into unstable. Till Kamppeter <till.kamppeter@gmail.com> for his integration of cups-filters and cups-browsed with CUPS 2.2.2. Michael R. Sweet <msweet@apple.com> for developing the rastertopwg filter to support Apple raster.

See Also


CategoryPrinter