CUPS – Terminología de Impresión y Análisis

Unidad abstracta en CUPS para una impresora; tiene una uri de dispositivo, la cual representa conexión para el dispositivo, y puede existir con controlador clásico (archivo PPD desde paquete diferente) o sin ello (impresión sin controlador). Los apuntes que ve en los diálgos de impresión y configuración son aquellas colas de impresión. Pueden ser permanentes o temporales.

Las colas con controlador clásico o sin controlador de cola de impresión la cual necesita ser compartida más abajo de la red.

Las colas que no necesitan instalarse en absoluto: aparecen durante el diálogo de impresión y desaparecen una vez que la impresión se ha realizado correctamente. Se basan en la impresión sin controladores.

La cola se encuentra en una máquina diferente, donde se ejecuta otro proceso de cupsd, que en la máquina local. Suelen encontrarse en soluciones empresariales donde las impresoras no están en la misma red que los usuarios o si el administrador desea una supervisión centralizada de todas las impresoras. En estas soluciones, los usuarios configuran cups-browsed para instalar la cola remota de CUPS como colas locales mediante la directiva BrowsePoll, o instalan una cola específica mediante GNOME. Podría haber una solución para redirigir los mensajes mDNS que el servidor CUPS anuncia a las redes con usuarios, pero aún no la he configurado correctamente.

Estos son los archivos binarios y PPD que deben instalarse para que el dispositivo funcione. Esta es una forma antigua de dar soporte a los dispositivos, que desaparecerá en el futuro.

La mayoría de los dispositivos modernos (2010+) cumplen con los estándares AirPrint, Mopria o IPP Everywhere, lo que significa que no necesitan un controlador clásico para imprimir. Estos dispositivos tienen implementado IPP (Protocolo de Impresión por Internet) 2.0+, pueden anunciarse a través de mDNS y admiten formatos de documento como PDF, PCLm, JPEG, Apple Raster o PWG Raster.

Hay varios requisitos previos que deben cumplirse en el sistema operativo para tener acceso a la función sin controlador:

Cómo la impresora sin controlador funciona bajo el techo (ponlo simplemente):

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 manual how to check if your printer is capable of driverless printing.

Esta impresión es similar a imprimir sin controlador en materia de configuración de una cadena de filtro, pero:

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.

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

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 ps-printer-app, ghostscript-printer-app, hplip-printer-app and 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 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 manual how to check for IPP-over-USB.

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.

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.