quick-docs/modules/ROOT/partialsdelete/2delete-con_cups-terminology-for-printing-and-scanning.adoc

[id='con_cups-terminology-for-printing-and-scanning']
= Terminology for printing and scanning

== Printing

=== Print queue

Abstraction unit in CUPS for a printer - it has a device uri, which represents connection to the device, and can exist with classic driver (PPD file from different package) or without (driverless printing). The entries you see in print dialogs and settings are those _print queues_. They can be _permanent or temporary_.

=== Permanent print queues

The queues with classic driver or driverless print queue which need to be shared further down the network.

=== Temporary print queues

The queue which don't need to be installed at all - they show up during print dialog and they disappear once the printing is done successfully. They rely on _driverless printing_.

=== Remote CUPS queue

The queue on the different machine, where other cupsd process is running, than on the local machine. They are usually found in enterprise solutions, where printers aren't in the same network as users or if admin wants a centralized monitoring above all printers. In such solutions, users set up _cups-browsed_ to install remote CUPS queue as local queues via _BrowsePoll_ directive, or install a specific queue via GNOME. There can be a solution how to redirect mDNS messages which CUPS server advertises to the networks with users, but I haven't been to setup this correctly yet.

=== Classic drivers

Those are the binaries and PPD files, which need to be installed for the device to work. This is older way of supporting devices, which will go away in the future.

=== Driverless printing (wireless/ethernet)

Most of modern devices (2010+) complies to AirPrint, Mopria or IPP Everywhere standard, which means they don't need a classic driver for being able to print. Those devices have IPP (Internet Printing Protocol) 2.0+ implemented within, are capable to 'advertise' themselves via mDNS and they support document formats like PDF, PCLm, JPEG, Apple Raster or PWG Raster.

There are several prerequitises which need to fulfill in OS to have an access to the driverless feature:

* avahi-daemon must run
* there needs to be a '.local' address resolver active - systemd-resolved or nss-mdns
* the device itself must have IPP port (631) and Bonjour/MDNS enabled
* IPP and MDNS need to be enabled in firewall

How does the driverless printing work under the roof (put it simply):

* CUPS sees the printer in mDNS messages via Avahi
* CUPS will find out the printer capabilities via IPP
* if there is a print job, CUPS will set up the filter chain to convert the incoming file into document format which printer understands (Apple Raster, PDF, PWG Raster, PCLm, JPEG)

In case it is needed, PPD file is generated by PPD generator in CUPS or by _driverless_ binary.

One of the features which use driverless printing is _CUPS temporary queues_.

See xref:cups-useful-tricks.adoc#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing[manual] how to check if your printer is capable of driverless printing.

=== Printing using a driver

This printing is similar to driverless printing in matter of setting up a filter chain, but:

* it can use limited mDNS and IPP functionality or it doesn't use them at all
* all information about device capabilities is taken from PPD (Postscript Printer Description) file
* can use a specialized filters and specialized communication with the device (depends on driver)

The downsides of this approach is to rely on 3rd party drivers, you need to always install a permanent queue for it and it will go away in the future.

=== Raw queue

No filters are started by CUPS if you print to such a queue, the data are sent as they are to the target, no options are applied by CUPS - all regardless of incoming document format. It is required the application you use for printing sends a printer-ready data (in the correct format, with all chosen options applied) or the destination is set to the desired settings (f.e. printer/print server is set to do two-sided-long-edge duplex with grayscale settings, so every document printed will have this settings and user won't  be able to change it in an application).

This approach is usually set for printing to older label printers via a specific application, or, in the past, for printing to remote CUPS queue. Because CUPS has no way how to provide common user experience (finding out printer properties, converting various document formats into a document format the printer accepts, setting printing options) for such queues, their usage is deprecated and it will be removed in the future (in CUPS 3.X).

=== Raw printing

Raw printing happens if CUPS receives a file in document format which printer accepts directly and CUPS recognizes the format based on rules from its MIME database. CUPS daemon doesn't start any filters for such a job (it might encapsulate options into IPP packet, if the connection with the printer is over IPP) with exception for PDFs, where the _pdftopdf_ filter is started to apply generic settings like scaling, rotation etc. Raw printing itself happens on print queues with classic driver and driverless print queues. This functionality stays with CUPS 3.X.

The difference between raw printing and raw queue is the raw printing is a situation which happens if CUPS daemon gets a file in format which printer accepts, so the daemon does not spawn additional filters for such job (with PDF being an exception), and spawns filters for document formats, which are not acceptable by the printer directly, whereas the raw queue is a queue, which CUPS daemon does not spawn any filters in any circumstances, and behaves like a Unix pipeline.

=== Printer applications

The binaries which provide support for older devices which aren't capable of complying to driverless standards. The core idea is they will be capable of accepting the old driver and then advertise itself as a device capable of driverless printing. Then the new CUPS will be able to see them and user will be able to print via them as if they were temporary queues. The currently available printer applications in Fedora are _ippeveprinter_ (a part of CUPS - see cups-printerapp package) and _lprint_ (provides support for devices which requires raw printing - mostly label printers). Other printer applications like https://github.com/OpenPrinting/ps-printer-app[ps-printer-app], https://github.com/OpenPrinting/ghostscript-printer-app[ghostscript-printer-app], https://github.com/OpenPrinting/hplip-printer-app[hplip-printer-app] and https://github.com/OpenPrinting/gutenprint-printer-app[gutenprint-printer-app] are currently available as SNAPs until cups-filters 2.0 is released and packaged. Printer applications are, except for _ippeveprinter_, written using _PAPPL_ library, so such printer application provides CLI interface and Web Interface for users to interact with.

=== Driverless printing (USB)

Driverless printing has its variant for devices which are connected via USB - it is covered by 'IPP over USB' standard. For make it work, you need 'ipp-usb' package, which will register the device with Avahi on localhost - then USB device will look as a wireless/ethernet device. The discovery/printing looks the same as with a wireless/ethernet device with driverless support.

See xref:cups-useful-tricks.adoc#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing[manual] how to check for IPP-over-USB.

== Scanning

=== Classic scanning (via hplip and sane-backends)

The classic scanning works via backends, which are binaries for communication with device. There are several backends, usually created by reverse engineering communication between scanner and MS Windows driver. None of classic backends implements a protocol, which is compatible with most devices available.

=== Driverless scanning

The driverless scanning uses sane-escl (not built in Fedora) and sane-airscan backends for communicating with newer devices. Those newer devices usually support eSCL (based on AirScan protocol by Apple) or WSD (Web Services for Devices by Microsoft), which _sane-airscan_ is able to use.

Regarding USB scanning, it has the same requirement as printing. The device must support IPP over USB driverless standard and _ipp-usb_ package must be installed to get driverless scanning via USB - the package is required because it creates a driverless interface over USB interface which _sane-airscan_ uses for driverless communication with device.