En los siguientes párrafos se describen los problemas de hardware y software más frecuentes durante la impresión así como diversos métodos para solucionar o evitar estos problemas.
Las impresoras GDI son aquellas que se manejan con secuencias de control especiales y sólo funcionan con los sistemas operativos para los que existe un controlador del fabricante. GDI es una interfaz de programación para dispositivos gráficos desarrollada por Microsoft. El problema no es la interfaz de programación, sino la restricción del acceso a la impresora a través del lenguaje propietario de la impresión.
Algunas impresoras pueden operar tanto en modo GDI como en uno de los lenguaje de impresión estándar. Para algunas impresoras GDI existen controladores propietarios del fabricante. Los inconvenientes de los controladores de impresora propietarios es que no se puede garantizar el funcionamiento con el sistema de impresión actualmente instalado ni el funcionamiento correcto de las distintas plataformas de hardware. Las impresoras que entienden un lenguaje de impresión estándar no dependen de una versión específica del sistema de impresión ni de una plataforma de hardware determinada.
Normalmente resulta más económico comprar directamente una impresora soportada en lugar de gastar tiempo en la adaptación de un controlador de Linux propietario. Con una impresora correcta, el problema de controladores se resuelve para siempre. Nunca más hará falta instalar y configurar controladores especiales o conseguir actualizaciones de controladores cuando avance el desarrollo del sistema de impresión.
Si no existe ningún archivo PPD adecuado para una impresora PostScript
dentro del paquete manufacturer-PPDs, debería ser
posible utilizar el archivo PPD del CD de controladores del fabricante de
la impresora o descargar un archivo PPD adecuado de su página web.
Los archivos PPD que aparecen como archivo (.zip) o como archivo zip
autodescomprimible (.exe) pueden ser desempaquetados
con unzip. Aclare primero los términos de licencia del
archivo PPD y compruebe a continuación con el programa
cupstestppd si el archivo PPD cumple la especificación
“Adobe PostScript Printer Description File Format Specification,
version 4.3.”. El resultado “FAIL” indica fallos
importantes que pueden ocasionar graves problemas. Los errores indicados
por cupstestppd han de resolverse. Si es necesario,
solicite directamente al fabricante de la impresora un archivo PPD
adecuado.
El método más seguro para que la impresora funcione consiste en conectarla directamente al primer puerto paralelo con la siguiente configuración en la BIOS:
Dirección E/S (I/O address): 378 (hexadecimal)
Interrupción: irrelevante
Modo: Normal,
SPP u
Output-Only
DMA: no se utiliza
Si no es posible acceder a la impresora a través del primer puerto paralelo
con esta configuración, se debe indicar explícitamente la dirección de
entrada y salida conforme a la configuración de la BIOS de la forma
0x378 en el archivo
/etc/modprobe.conf. Si hay dos puertos paralelos con
direcciones de entrada y salida 378 y
278, la entrada tiene que ser
0x378,0x278.
Si la interrupción 7 todavía está libre, se
puede activar la operación en modo interrupt con una entrada en el Ejemplo 12.1, “
/etc/modprobe.conf: interrupciones para el primer puerto paralelo
”. Antes
de activarlo, hay que comprobar en /proc/interrupts
las interrupciones utilizadas actualmente. Estas varían en función del
hardware empleado en ese momento. La interrupción para el puerto paralelo
tiene que estar libre. En caso de duda, utilice el modo polling con
irq=none.
Conecte la impresora directamente al ordenador y configúrela para efectuar una prueba como impresora local. Si la impresión funciona, los problemas tienen su origen en la red.
La red TCP/IP y la resolución de nombres tienen que funcionar correctamente.
El siguiente comando sirve para comprobar si realmente existe una
conexión TCP a lpd (puerto 515) en
el ordenador host:
netcat -z <host> 515 && echo ok || echo failed
Si no se puede acceder a lpd, puede ser que lpd no se esté ejecutando o que haya problemas generales de red.
Si lpd se está ejecutando correctamente en el
servidor, el usuario root
puede utilizar el siguiente comando para conseguir un informe de estado
de la cola queue en el ordenador remoto
host.
echo -e "\004queue" \ | netcat -w 2 -p 722 host 515
Si no hay respuesta de lpd significa que lpd no se
está ejecutando o que hay problemas generales de red. Una respuesta de
lpd debería aclarar por qué no es posible imprimir en
la cola queue del ordenador host.
Si recibe una respuesta como la del Ejemplo 12.2, “Mensaje de error de lpd”,
significa que el problema se encuentra en el lpd
remoto.
El siguiente comando sirve para detectar la existencia de un servidor
CUPS en la red, ya que este anuncia su disponibilidad cada 30 segundos
mediante un broadcast en el puerto UDP 631:
netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID
Si en la red existe un servidor CUPS emitiendo broadcasts, la salida del comando será parecida a la del Ejemplo 12.3, “Broadcast del servidor CUPS”:
El siguiente comando comprueba la existencia de una conexión TCP a
cupsd (puerto 631) en el ordenador
host:
netcat -z host 631 && echo ok || echo failed
Si no hay conexión a cupsd, significa que
cupsd no se está ejecutando o que hay problemas
generales de red. Si cupsd se está ejecutando
correctamente en el servidor, el comando lpstat -h host -l
-t genera un informe (posiblemente muy extenso) de estado de
todas las colas en el ordenador remoto host.
Con el siguiente comando se comprueba si la cola
queue del ordenador
host acepta una tarea de impresión compuesta
por un único retorno de carro; es decir, no se deberá imprimir nada o,
como máximo, una hoja en blanco.
echo -en "\r" \ | lp -d queue -h host
En ocasiones hay problemas con el spooler de impresión de un servidor de impresión (printserver-box), sobre todo cuando tienen que manejar un gran número de tareas de impresión. Dado que el problema radica en el spooler del servidor, no hay solución directa. La solución indirecta consiste en evitar el spooler accediendo directamente a la impresora a través de socket TCP. Consulte a este respecto la Sección 12.5.2, “Impresoras de red”.
De este modo el servidor de impresión sólo trabaja como conversor entre
los diferentes formatos de datos (red TCP/IP y conexión local). Para
realizar el desvío hace falta conocer el puerto TCP correspondiente en
el servidor de impresión. Con impresora y servidor de impresión
encendidos, se puede utilizar para ello el programa
nmap del paquete nmap. Por
ejemplo, el comando nmap
dirección-IP devuelve el siguiente
resultado para un servidor de impresión:
Port State Service 23/tcp open telnet 80/tcp open http 515/tcp open printer 631/tcp open cups 9100/tcp open jetdirect
La salida de nmap significa que se puede acceder al servidor a través
del puerto 9100. En su configuración predeterminada,
nmap sólo comprueba una lista de puertos conocidos
que se incluye en en /usr/share/nmap/nmap-services.
Para comprobar todos los puertos posibles, utilice el comando:
nmap
-p from_port-to_port dirección-IP.
Esta operación puede llevar bastante tiempo; véase también la página man
de nmap.
Introduzca un comando como:
echo -en "\rHolaMundo\r\f" | netcat -w 1 IP-address port cat file | netcat -w 1 IP-address port
para enviar directamente cadenas de caracteres o archivos a un puerto determinado para comprobar si es posible acceder a la impresora a través de ese puerto. En caso afirmativo, se imprimirán las palabras “HolaMundo”.
El sistema de impresión da por terminada la tarea de impresión cuando CUPS finaliza la transferencia de datos a la impresora. Si la impresión posteriormente fracasa (por ejemplo porque la impresora no interpreta los datos de impresión correctamente), el sistema de impresión no se da cuenta de ello. En caso de que la impresora no sea capaz de imprimir los datos correctamente, deberá buscarse un archivo PPD más adecuado.
Después de varios intentos fallidos de enviar los datos a la impresora, el
dorsal de CUPS (por ejemplo usb o
socket) notifica un error al sistema de impresión
(concretamente a cupsd). El dorsal determina a partir de
cuántos intentos se notifica un error. Dado que no tiene sentido realizar
intentos adicionales, cupsd desactiva
(disable) la cola en cuestión. Después de solucionar el
problema, el administrador del sistema tiene que reactivar la cola mediante
el comando /usr/bin/enable.
Un servidor de red CUPS que ofrece sus colas por medio de browsing, recibe las tareas de impresión desde los cupsd que se ejecutan localmente en los ordenadores cliente. Estos cupsd locales se encargan de recibir las tareas de impresión de las aplicaciones y pasarlas al cupsd del servidor. Cada vez que cupsd recibe una tarea de impresión le asigna un número, por lo que el número de tarea en cliente y en el servidor no es el mismo. Puesto que la tarea de impresión se reenvía inmediatamente y el cupsd del cliente da por concluida su función cuando envía dicha tarea al cupsd del servidor, no es posible borrar en el servidor una tarea de impresión con el número del cliente.
Para borrar la tarea en el servidor es preciso averiguar su número en el servidor por medio de un comando como lpstat -h print-server -o. Para ello es preciso que el servidor no haya completado la tarea de impresión (es decir, que todavía no la haya enviado a la impresora). Una vez que se conoce el número, es posible borrar la tarea de impresión con:
cancel -h print-server cola-número_tarea
Las tareas de impresión se mantienen en las colas y puede que se vuelvan a imprimir desde el principio tras apagar y encender la impresora o reiniciar el ordenador durante la impresión. Para eliminar permanentemente una tarea de impresión de la cola, utilice el comando cancel.
En caso de una tarea de impresión defectuosa o de interferencias en la transferencia de datos, la impresora no sabe interpretar los datos correctamente y el resultado es un gran número de hojas impresas llenas de caracteres sin sentido. Si esto sucede, realice los siguientes pasos:
Retire el papel de las impresoras de chorro de tinta o abra la bandeja de papel en las impresoras láser para detener la impresión. Las impresoras de calidad disponen de un botón para detener la tarea de impresión en curso.
Debido a que la tarea de impresión permanece en la cola hasta su envío
completo a la impresora, normalmente todavía se encontrará allí tras
apagar ésta. Utilice el comando lpstat -o o
lpstat -h print-server -o
para comprobar cuál es la cola de impresión actualmente activa y borre la
tarea con cancel
cola-número_tarea
o con cancel -h
print-server
cola-número_tarea
.
En caso de que se sigan transmitiendo datos a la impresora a pesar de haber borrado la tarea de la cola, compruebe si se está ejecutando un proceso dorsal de CUPS para la cola en cuestión y termínelo en caso afirmativo. El comando fuser -k /dev/lp0 termina por ejemplo todos los procesos que aún estén accediendo a la impresora en el puerto paralelo.
Desconecte la impresora completamente desenchufándola unos minutos. Posteriormente vuelva a introducir papel y encienda la impresora.
Se recomienda el siguiente procedimiento para localizar problemas en el sistema de impresión CUPS:
Active el nivel de registro LogLevel debug en
/etc/cups/cupsd.conf.
Detenga cupsd.
Elimine /var/log/cups/error_log* para no tener que
buscar en archivos demasiado grandes.
Inicie cupsd.
Repita la operación que ha causado el error.
Examine los mensajes disponibles en
/var/log/cups/error_log* para averiguar la causa del
problema.
En nuestra base de datos de soporte (SDB) se incluyen las soluciones a muchos problemas específicos. En caso de dificultades con impresoras, consulte los artículos Installing a Printer y Printer Configuration from SUSE LINUX 9.2 a los que puede acceder introduciendo el término de búsqueda “printer”.