"Después del juego es antes del juego"
Sepp Herberger

martes, 29 de diciembre de 2015

Configuracion de una impresora Multifunción Epson WorkForce Pro WF-8590 en el IES

En esta lluvia de millones que nos atenaza nos han llegado unas impresoras multifunción A3 Epson WorkForce Pro WF-8590 Series que nos vendrán muy bien con la impresión de planos y diseños varios y con la cartelería del centro. El problema es que son de inyección de tinta y esta por ver cuanto cuestan los repuestos y que tal aguantan nuestro verano extremo-y-duro. Ya haré un memorándum el próximo septiembre si sobrevivimos a la flama.

La he configurado para el uso normal sin problemas, pero he tenido algunos contratiempos para hacerla funcionar tal como quiero y paso a relatarlos por si hay que usarlos otra vez.

Drivers para Linux.

Los drivers se descargan como paquete .deb de la página de epson, en concreto estoy usando estos:
# dpkg -l | grep epson
ii  epson-inkjet-printer-escpr            1.6.1-1lsb3.2                     i386         Epson Inkjet Printer Driver (ESC/P-R) for Linux
En cups se da de alta sin problema, apareciendo como Epson WF-8590 (Seiko Epson Corporation LSB 3.2) (color, 2-sided printing).

Un primer problema es que al imprimir desde Linux lo hace con tonos muy tenues, como si estuviese en modo borrador. Eso se soluciona configurando en cups, dentro de las propiedades predeterminadas de la impresora el parámetro "Media Type->Plain papers – high".

Google Cloud Print.

La impresora es compatible con Google Cloud Print, lo que permite asociarla a una cuenta de Gmail e imprimir en ella desde cualquier lugar del mundo y desde la Estación Espacial Internacional habiendo iniciado sesión en dicha cuenta con Google Chrome. Esta opción es muy cómoda para la directiva, que puede mandar imprimir desde casa y encontrarse las cosas impresas al llegar al centro.

En las pruebas preliminares esta opción fallaba: al intentar registrar la impresora me decía que no había conexión y que revisase la configuración de red, pero mi compañero Esteban decía que en su IES la habían hecho funcionar: actualicé el Firmware a la última versión con el programa de Epson para tal fin (en esta ruta está dentro de la opción firmware), me aseguré de que el puerto 5222 estaba abierto en mi red (con http://portquiz.net:5222/ se comprueba en un periquete), .....

Al final el problema estaba en que, preso de la paranoia, había puesto un filtrado IP en la impresora para permitir imprimir solo a determinadas IP del IES. Dicho filtrado IP por lo visto también afecta a Google Cloud Print e imposibilita su uso. Desactivando el filtrado en cuestión se resuelve el problema. Es una lata dejarlo asi pero no hay otro remedio.

Conteo de paginas con tea4cups y pkpgcounter

Como siempre, al ser una impresora de red, me interesa que se cuenten las páginas que se imprimen desde determinados sitios. En las pruebas descubro que pkpgcounter siempre cuenta 1 página, independientemente del tamaño del documento. Estaba claro que no era capaz de procesarlo bien.

Como otras veces, lo primero que hago es capturar el fichero bruto .prn enviado a la impresora mediante el script asociado a tea4cups y me dispongo a analizarlo.

Después de investigar un rato averiguo que el fichero viene en formato ESC/P-R, que es una evolución del formato ESC/P2 tradicional de Epson. Pkpgcounter lo reconoce como ESC/P2 pero al ser un formato diferente no es capaz de contar bien las páginas. Tenía que averiguar cual es la cadena de bytes que hace la separación de páginas.

Afortunadamente, el driver de Epson es GPL, lo cual significa que tenemos el código fuente disponible. Lo descargo del primer lugar donde encuentro los fuentes: la página del paquete en Ubuntu (es la version 1.1.1, un poco antigua, pero no creo que esa parte haya cambiado mucho). Es un fichero epson-inkjet-printer-escpr-1.1.1.targ.gz que descomprimo y tras investigar un rato en los ficheros .c y .h y con un poco de intuición encuentro, que en el fichero ./epson-inkjet-printer-escpr-1.1.1/lib/escpr_cmd.c:

static const ESCPR_UBYTE1 cmd_EndPage[] = {
     0x1B,  'p', 0x01, 0x00, 0x00, 0x00,  'e',  'n',  'd',  'p'};
Por tanto, esta secuencia de 10 bytes son los números mágicos del fin de pagina.

Para que se tengan en cuenta al ejecutar pkpgcounter hay que modificar el fichero /usr/share/pyshared/pkpgpdls/escp2.py, quedando en negrita lo que debo añadir:
.....
....
marker4 = "\f\033@"
        
#  En ESC/P-R el fin de pagina es
#   {0x1B,  'p', 0x01, 0x00, 0x00, 0x00,  'e',  'n',  'd',  'p'}
#  Sacado del codigo fuente fichero escpr_cmd.c
marker5 = "\033p\001\000\000\000endp"
     
pagecount2 = max(data.count(marker2r), data.count(marker2rn))
pagecount3 = data.count(marker3)
pagecount4 = data.count(marker4)
pagecount5 = data.count(marker5)
         
if pagecount2 :    
 return pagecount2
elif pagecount3 > 1 :  
 return pagecount3 – 1
elif pagecount4 :    
 return pagecount4
elif pagecount5>=1:
 return pagecount5
else :
 return int(pagecount1 / 2)
....
....

Y con esto conseguimos que cuente bien este formato. Mandaría el parche al creador de pkpgcounter, pero ya he mandado otro y no me ha dicho nada, lo cual me hace pensar que nadie mantiene ya el programa. Bueno, pues aquí queda.

Compartir la impresora desde CUPS.

Al compartir la impresora desde CUPS con una máquina que hará de servidor de impresión me surgió un problema adicional: si imprimo desde clientes Windows y algunos Linux (tengo varios tipos de Debian, Ubuntu, Mint y luego mi Manjaro), los trabajos se pierden en el limbo y nunca llegan, sin dar ningún error visible.

Los únicos que no se perdían eran los enviados desde aquellos clientes en que la versión del driver era exactamente igual en máquina cliente y servidora. Por supuesto, eso eliminaba de forma fulminante a los Windows como posibles clientes y con ello el control de páginas impresas mediante tea4cups. Había que encontrar una solución.

Tras varias pruebas descubro el truco para evitarlo: dar de alta la impresora en el servidor de impresión con el driver “Local Raw Printer”, que debe ser un driver que envía las cosas tal cual le llegan, sin procesar. De esta manera el fichero de impresión llega ya preparado en ESC/P-R desde el driver del cliente, las páginas son contadas por pkpgcounter y todo es reenviado sin mayor problema a la impresora.

El único problema que tiene esto es intentar imprimir algo en local en la máquina servidora. Al ser el driver “Local Raw Printer” se envía sin procesar y obtenemos esa impresión tan espectacular de folios y folios de lo que los usuarios semiavanzados llaman “código máquina”.

Conteo de impresión a varias copias.

Otro problema que encontré con determinados drivers de Linux es que si enviaba una impresión de varias páginas y varias copias se producía un error muy irritante que sucede a veces: si el documento es de 3 paginas y se hacen 2 copias, el driver envía un documento de 6 páginas (3 x 2) y dice que haga 2 copias. La impresora ignora el parámetro número de copias y todo sale bien, excepto el conteo en tea4cups que cuenta 6x2=12 páginas en lugar de las 6 impresas.

Para evitarlo hay que modificar el script de seguimiento de impresión que es invocado desde tea4cups en los PC donde el driver haga esa pirula, quedando:

# cat /../.../..../ seguimiento_impresion

.....
.....
#Hay que convertir el valor de TEACLIENTHOST en un nombre de equipo.
if [ "$TEACLIENTHOST" == "localhost" -o "$TEACLIENTHOST" == "" ]
then
   equipo=$(hostname -s)
else
   if valid_ip $TEACLIENTHOST
   then
      equipo=$(host $TEACLIENTHOST | cut -d" " -f5 | cut -d"." -f1)
   else
      equipo=$TEACLIENTHOST
   fi
fi

#La impresora VGIM_JEFATURA mete el numero de copias en el conteo de paginas. 
# Un documento de 2 paginas impreso con 3 copias
# se manda con determinados drivers de linux  como "documento de 6 paginas con 3 copias", 
# lo que da un conteo de 18 en lugar de 6. Hay que corregir eso ajustando el $paginas que se ha
# obtenido con pkpgcounter. 
if [ "$TEAPRINTERNAME" == "VGIM_JEFATURA" ]
then
  $paginas = $(( $paginas / $TEACOPIES ))
fi

.....
.....

exit 0

De esta manera, al dividirlo por el número de copias el número de páginas coge su valor correcto.

Y con estas pequeñas recetas ya tenemos nuestra impresora operativa e integrada en la red del centro. Seguiremos informando....

1 comentario:

  1. Alfonso, no sé si proponerte premio novel de ciencias o de literatura, pero me lo paso genial y me descubro. Ojalá tenga tiempo de probar estas cosas; me he quedado en lo de buscar el driver. Lo de que el firewall no te deja google print, es una pena, pero seguro que hay solución, otra cosa es tiempo para encontrarlo...Lo dicho, gracias mil

    ResponderEliminar