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

Brandon Nielsen, Zdenek Dohnal Versión F31 onwards Last review: 2021-06-16

Imprimir

Cola de impresión

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.

Colas de impresión permanentes

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.

Colas de impresión temporales

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.

Cola remota de CUPS

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.

Controladores clásicos

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.

Impresión sin controladores (sin cable/ethernet)

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:

  • avahi-daemon debe ejecutar

  • debe haber un solucionador de direcciones '.local' activo - systemd-resolved o nss-mdns

  • el dispositivo en sí debe tener el puerto IPP (631) y Bonjour/MDNS habilitados

  • IPP y MDNS necesitan estar activados en cortafuegos

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

  • CUPS ve la impresora en los mensajes mDNS a través de Avahi

  • CUPS descubrirá las capacidades de la impresora a través de IPP

  • si hay una tarea de impresión, CUPS configurará el encadenado de filtro para convertir el archivo de entrada a un formato documental el cual la impresora comprende (Apple Raster, PDF, PWG Raster, PCL, JPEG)

En el caso es necesario, el archivo PPD es generado por el generador PPD en CUPS o por binario sin unidad.

Una de las características las cuales utilicen impresión sin controlador es colas temporales de CUPS.

Consulte el manual acerca de como marcar si su impresora es capaz de imprimir sin unidad.

Imprimir utilizando un controlador

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

  • puede utilizar funcionalidad mDNS e IPP limitada o no utilizarlos para nada

  • toda la información sobre las capacidades del dispositivo se toma desde el archivo PPD (Postscript Printer Description)

  • puede utilizar una comunicación de filtros y especializado con el dispositivo (dependiente del controlador)

La desventaja de este enfoque es que depende de controladores de terceros, es necesario instalar siempre una cola permanente para ello y desaparecerá en el futuro.

Cola sin formato (cruda)

CUPS no inicia ningún filtro al imprimir en una cola de este tipo. Los datos se envían tal cual al destino y CUPS no aplica opciones, independientemente del formato del documento entrante. Es necesario que la aplicación que utilice para imprimir envíe datos listos para imprimir (en el formato correcto, con todas las opciones seleccionadas aplicadas) o que el destino tenga la configuración deseada (por ejemplo, la impresora/servidor de impresión está configurado para imprimir a doble cara por el borde largo con configuración de escala de grises, de modo que cada documento impreso tenga esta configuración y el usuario no pueda cambiarla en ninguna aplicación).

Este enfoque suele configurarse para imprimir en impresoras de etiquetas antiguas mediante una aplicación específica o, anteriormente, para imprimir en una cola CUPS remota. Dado que CUPS no puede ofrecer una experiencia de usuario común (conocer las propiedades de la impresora, convertir varios formatos de documento a un formato compatible con la impresora y configurar las opciones de impresión) para estas colas, su uso está obsoleto y se eliminará en el futuro (en CUPS 3.X).

Impresión en crudo

La impresión sin procesar se realiza si CUPS recibe un archivo en formato de documento que la impresora acepta directamente y CUPS reconoce el formato según las reglas de su base de datos MIME. El demonio de CUPS no inicia ningún filtro para este tipo de trabajo (podría encapsular opciones en paquetes IPP si la conexión con la impresora es mediante IPP), excepto para archivos PDF, donde se inicia el filtro pdftopdf para aplicar ajustes genéricos como escalado, rotación, etc. La impresión sin procesar se realiza en colas de impresión con controlador clásico y sin controlador. Esta funcionalidad se mantiene en CUPS 3.X.

La diferencia entre la impresión sin procesar y la cola sin procesar es que la impresión sin procesar es una situación que ocurre si el demonio CUPS obtiene un archivo en un formato que la impresora acepta, por lo que el demonio no genera filtros adicionales para dicho trabajo (con PDF como excepción) y genera filtros para formatos de documento que la impresora no acepta directamente, mientras que la cola sin procesar es una cola en la que el demonio CUPS no genera ningún filtro bajo ninguna circunstancia y se comporta como un conducto de Unix.

Aplicaciones de Impresora

Los binarios que ofrecen soporte para dispositivos antiguos que no cumplen con los estándares de impresión sin controlador. La idea principal es que acepten el controlador antiguo y se presenten como dispositivos capaces de imprimir sin controlador. De esta forma, el nuevo CUPS podrá verlos y el usuario podrá imprimir a través de ellos como si fueran colas temporales. Las aplicaciones de impresora disponibles actualmente en Fedora son ippeveprinter (parte de CUPS; consulte el paquete cups-printerapp) y lprint (compatible con dispositivos que requieren impresión sin procesar, principalmente impresoras de etiquetas). Otras aplicaciones de impresora como ps-printer-app, ghostscript-printer-app, hplip-printer-app y gutenprint-printer-app están actualmente disponibles como SNAP hasta que se publique y empaquete cups-filters 2.0. Las aplicaciones de impresora, excepto ippeveprinter, se escriben con la biblioteca PAPPL, por lo que estas aplicaciones ofrecen una interfaz CLI y una interfaz web para la interacción de los usuarios.

Imprimir sin controlador (USB)

La impresión sin controlador tiene su variante para dispositivos conectados por USB, que está cubierta por el estándar "IPP sobre USB". Para que funcione, se necesita el paquete "ipp-usb", el cual registrará el dispositivo con Avahi en el host local. El dispositivo USB se visualizará como un dispositivo inalámbrico/Ethernet. El proceso de detección e impresión es el mismo que con un dispositivo inalámbrico/Ethernet compatible con la impresión sin controlador.

Consulte el manual como comprobar para IPP-over-USB.

Analizar

Análisis clásico (por medio de hplip y backend sane)

El análisis clásico funciona mediante segundo plano, que son archivos binarios para la comunicación con el dispositivo. Existen varios segundo plano, generalmente creados mediante ingeniería inversa de la comunicación entre el escáner y el controlador de MS Windows. Ninguno de los segundos planos clásicos implementa un protocolo compatible con la mayoría de los dispositivos disponibles.

Análisis sin controlador

El análisis sin controlador utiliza los sane-escl de segundo plano (no integrado en Fedora) y sane-airscan para comunicarse con dispositivos más nuevos. Estos dispositivos suelen ser compatibles con eSCL (basado en el protocolo AirScan de Apple) o WSD (Servicios Web para Dispositivos de Microsoft), que sane-airscan puede utilizar.

En cuanto al análisis USB, los requisitos son los mismos que los de la impresión. El dispositivo debe ser compatible con el estándar IPP sobre USB sin controlador y debe tener instalado el paquete ipp-usb para analizar sin controlador por USB; el paquete es necesario porque crea una interfaz sin controlador sobre la interfaz USB que sane-airscan utiliza para la comunicación sin controlador con el dispositivo.