CUPS; Problemas conocidos

cups-browsed pierde algunas veces la conexión con el servidor de impresión (normalmente con los más antiguos, como cups-1.4.2) cuando el portátil cambia la conexión de red (cambio de red WiFi o después de haber estado hibernado/suspendido). Usted puede volver a imprimir otra vez cancelando sus trabajos y reiniciando cups-browsed mediante

La creación de colas de impresión locales lleva mucho tiempo en algunas impresoras con archivos PPD de gran tamaño, por lo que la conexión http agotará el tiempo de espera y se creará un bucle infinito de creación de colas de impresión locales. Para resolver este problema, añada

en /etc/cups/cups-browsed.conf, donde N es el número de segundos tras el cual la conexión es desconectada. Entonces reinicia el servicio cups-browsed. Esta opción actualmente está en Fedora 27 y posterior.

Este tema está conectado a colas remotas de cups, las cuales están advertidas por versión CUPS más antiguas (utilizando a continuacón cups-1.5, p.ej. RHEL 6) El explorador de CUPS crea colas de impresora local nombrada por los ID de DNS-SD de la impresora por defecto y nombrando por cola de CUPS remotas está habilitada frente a añadiendo:

al /etc/cups/cups-browsed.conf y reinicie el servicio cups-browsed.

Cuando tu impresora tarda mucho en imprimir (desde tu perspectiva) o no imprime en absoluto (algunas impresoras Xerox presentan este problema con el renderizador gs, por lo que solo funcionan con el renderizador pdftops), puedes intentar cambiar el renderizador PostScript predeterminado. En Fedora, el renderizador predeterminado para la mayoría de las impresoras es el filtro gs de Ghostscript, pero para las impresoras Brother, Minolta y Konica Minolta se utiliza el filtro pdftops de Poppler; esta configuración se denomina híbrida.

Otras configuraciones de renderizador disponibles son gs (de Ghostscript), pdftops y pdftocairo (de Poppler), mupdf (de mupdf) y acroread (de Adobe Reader, no disponible en los repositorios oficiales de Fedora). A continuación, puede configurar un renderizador predeterminado diferente para su cola de impresión de la siguiente manera:

¡CUIDADO! La mayoría de los problemas de impresión lenta se deben a las aplicaciones de creación de PDF, que generan archivos PDF defectuosos. Este archivo defectuoso suele ser la causa principal del problema. En resumen, el problema de impresión lenta puede repetirse con otro archivo PDF, por lo que la decisión final depende del usuario: si desea imprimir rápido y probablemente cambiar el renderizador predeterminado, o si la impresión lenta no le resulta tan crítica.

Este defecto afecta a todas las aplicaciones que utilizan el diálogo de impresión de GTK. El diálogo de GTK obtiene información sobre la cola de impresión disponible de dos fuentes: los mensajes mDNS de Avahi y CUPS. Esta cola de impresión ficticia/duplicada es una cola que GTK crea en su diálogo basándose en los mensajes de Avahi, pero no existe en CUPS, ya que nadie la ha creado. Posteriormente, GTK se comporta como si existiera en CUPS. Por lo tanto, cada vez que un usuario quiere imprimir, GTK envía una solicitud a CUPS para esta cola, pero CUPS la descarta porque la cola no existe.

La funcionalidad la cual GTK intenta hacer se denomina colas temporales CUPS. Los desarrolladores de GTK están trabajando en una solución inmediata en bugzilla. El plan a futuro es utilizar el backend cpdb-backend-cups en GTK, pero actualmente nos centramos en la reparación intermedia.

CUPS a veces tiene problemas con algunos tipos de FQDN; esto significa que cuando se usa un FQDN en la directiva BrowsePoll del archivo /etc/cups/cups-browsed.conf, CUPS no lo reconoce como un nombre de host válido. Esto se soluciona añadiendo lo siguiente:

into /etc/cups/client.conf y reiniciando el servicio cups.

Una situación similar puede ocurrir con escáneres compatibles con sane-airscan. Algunos dispositivos declaran menos opciones a través de protocolos (por ejemplo, IPP 2.0+, WSD, eSCL) que admiten soluciones sin controlador, en comparación con los controladores clásicos. Generalmente, se trata de un problema con el firmware del dispositivo, lo cual se puede verificar comprobando el resultado del siguiente comando:

El comando realiza la misma solicitud IPP que se ejecuta cuando aparece una cola temporal en el cuadro de diálogo de impresión o cuando se instala la cola de forma permanente. Las opciones de la impresora se configuran a partir de la respuesta IPP a esta solicitud; por lo tanto, si la opción no está presente en la respuesta, CUPS no puede generarla. La solución consiste en intentar actualizar el firmware del dispositivo, informar del problema al fabricante y en bugzilla adjuntando las bitácoras.

Fedora 33 elevó los estándares de las normativas criptográficas, por lo que SSL y los protocolos TLS antiguos están deshabilitados a nivel de sistema. Este cambio impide la impresión mediante IPPS en dispositivos que no admiten los protocolos más recientes. Puede restablecer la compatibilidad con criptografía antigua en las normativas criptográficas mediante:

El cambio de normativa tiene un impacto transitorio en los dispositivos encontrados por cups-browsed, porque el demonio prefiere las URI IPPS si la impresora/servidor informa que están disponibles.

A veces, la compatibilidad con PDF en la impresora no funciona correctamente, lo que provoca una impresión ilegible. Si el controlador de la impresora también admite rasterización, es posible forzar la rasterización para el nuevo trabajo de impresión de la siguiente manera:

o bien, configure la rasterización de dicha impresora por defecto:

Este error común se debe principalmente a causas externas (caída del servidor, caída de la red), cuando wget intenta descargar un plugin, pero solo devuelve un mensaje de error. Está relacionado con el siguiente mensaje:

donde N es el valor devuelto por el comando wget (consulte el man wget), el cual es utilizado para descargar el complemento propietario. Las soluciones para este problema pueden variar: puede esperar a que los servidores vuelvan a estar operativos o intentar instalar el complemento, que puede descargar manualmente desde http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ (seleccione «Seleccionar e instalar una copia local existente del archivo del complemento» durante la ejecución de hp-setup o hp-plugin).

Este error puede ocurrir cunado hplip se instala desde el sitio web de HP, o si sus dependencias son paquetes mezclados de python2 y python3, o si se instalaron mediante pip. Se soluciona eliminando todos los paquetes de hplip (hplip, hplip-gui, hplip-libs, hplip-common, libsane-hpiao) y reinstalándolos desde los repositorios.

Las herramientas y componentes de interfaz gráfica de usuario (IGU) de los comandos de HP se han trasladado al subpaquete hplip-gui, ya que el paquete principal puede funcionar sin GUI, lo que reduce su tamaño. Como consecuencia, los comandos de HP deben ejecutarse con la opción -i para el modo interactivo, o bien es necesario instalar el subpaquete hplip-gui.

Herramientas, las cales requieren ser ejecutadas con la opción -i para la interfaz de línea de comandos o que requieren tener instalado hplip-gui para la IGU:

Herramientas, las cuales están en el hplip-gui:

Algunas impresoras HP no funcionan correctamente con las URI proporcionadas por CUPS (dnssd, usb, ipp) o requieren un plugin propietario de HP, que no está disponible en Fedora debido a problemas de licencia. Para estas impresoras, intente ejecutar:

para modo interactivo, o:

Para el modo gráfico. Este comando instala impresoras y escáneres HP. Si tiene problemas con su impresora o escáner HP (no se detecta, no imprime o la impresión es deficiente), intente instalarlo con el comando hp-setup. Si el problema persiste, reporte el error en Bugzilla, adjunte la salida de hp-setup e indique que intentó usar dicho comando.

Los dispositivos que requieren un complemento pueden dejar de funcionar tras actualizar a una versión más reciente de HPLIP; esto se debe a la comprobación de la versión del complemento en el código. Esta comprobación es necesaria para evitar inconsistencias cuando las nuevas funciones de HPLIP (de código abierto) requieren bibliotecas propietarias nuevas del complemento. Para que su impresora vuelva a funcionar, simplemente descargue e instale el complemento de nuevo con:

Los dispositivos los cuales requieren un complemento binario de código cerrado de HP necesitan tenerlo instalado cada vez que se inicia o reinicia el PC. El script de código cerrado de HP instala los complementos en directorios de solo lectura, por lo que se eliminan al iniciar o reiniciar Fedora. Como solución alternativa, si su dispositivo admite impresión y escaneo sin controladores, pruebe el paquete hplip-plugin desde RPMFusion o instale el complemento cada vez que desee imprimir.

El demonio ipp-usb mantiene abierto el puerto USB del dispositivo IPP-over-USB para cualquier posible comunicación IPP futuro, lo que bloquea el puerto para otras unidades (por ejemplo, HPLIP, gutenprint, sane-backends…​).

Para las impresoras la solución es desinstalar la cola con la unidad mediante:

y comience a usar uno del ipp-usb (como una cola temporal de CUPS o instale uno permanente; el URI del dispositivo predeterminado es ipp://localhost:60000/ipp/print).

En el caso de los escáneres, sane-airscan detecta automáticamente el dispositivo virtual de ipp-usb si este es compatible con los protocolos WSD o eSCL. Sin embargo, si el escáner era compatible con controladores clásicos como hplip o sane-backends y ahora ipp-usb lo detecta por ser compatible con el estándar sin controlador IPP-over-USB, el escáner antiguo seguirá apareciendo, pero no funcionará para escanear debido a un conflicto de USB. Esto ocurre porque los backends clásicos simplemente listan cualquier dispositivo que encuentren en las interfaces USB y que coincida con la descripción que admiten, pero no verifican si pueden comunicarse con el dispositivo hasta que intentan abrir el puerto USB para el escaneo. Esto supone un problema para las aplicaciones de escaneo, que seleccionan automáticamente el escáner anterior como opción predeterminada (como Simple Scan). Los usuarios deben seleccionar un escáner sin controlador de la lista de escáneres disponibles antes de escanear.

El dispositivo escáner detectado por los backends SANE clásicos puede desactivarse para que no aparezca entre los escáneres disponibles comentando su entrada en el archivo de configuración del backend, ubicado en /etc/sane.d, o el nombre completo del backend en /etc/sane.d/dll.conf//etc/sane.d/dll.d. Por ejemplo, los backends pixma y airscan detectan la serie Canon MF440, pero solo airscan funciona porque es un backend basado en protocolo de red, mientras que ipp-usb utiliza la interfaz USB. Por lo tanto, desactivaremos el backend pixma comentando su línea en /etc/sane.d/dll.conf:

Si el dispositivo creado por ipp-usb no se ajusta a sus necesidades (faltan las opciones que utiliza, o el dispositivo no funciona aunque sea compatible con IPP sobre USB), informe del problema junto con los registros del directorio /var/log/ipp-usb/ en bugzilla. ipp-usb admite configuraciones especiales, los cuales le permiten configurar el demonio para que ignore su dispositivo y pueda intercambiar a un controlador clásico. Los pasos son los siguientes:

Una situación similar puede ocurrir con impresoras compatibles con cualquier everywhere dispositivo o sin controladores driverless. Algunos dispositivos ofrecen menos opciones a través de protocolos (por ejemplo, IPP 2.0+, WSD, eSCL) que admiten soluciones sin controladores, en comparación con los controladores clásicos. Generalmente, se trata de un problema con el firmware del dispositivo, lo cual se puede verificar en los registros de depuración de sane-airscan y el tráfico de red. La solución consiste en intentar actualizar el firmware del dispositivo, informar del problema al fabricante y en bugzilla adjuntando las bitácoras.