[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ¿Involución en los sistemas de impresión?



El Thu, Jan 03, 2002 at 10:09:05AM -0300, Santiago Pastorino escribió:
> Simplemente excelente las explicaciones la verdad no tenía ni idea de
> todo esto.
> Me queda una sola duda, con respecto al tema del borrado de la cola y la
> cancelación de la impresión, yo con cups borro la cola, ¿por que tengo
> que apagar la impresora, prenderla y repetir ese preceso 2 veces más
> para que la impresora paré? o sea apagarla 3 veces, ¿no se supone que en
> la primer apagada se borra el buffer? y entonces que es lo que sigue
> haciendo la impresora.

 
 Pues hace lo que te comenté, hay 3 partes básicas en los sistemas de
impresión..

 cola -> buffer de dispositivo *nix -> buffer de dispositivo fisico
(impresora)

 Si tu borras la cola, has de esperar a que la impresora termine con
los otros 2 buffers, osea .. a que se acabe lo que tiene en su buffer
interno (si la apagas, esto se borra), y a que acabe la información
que hay en el buffer de dispositivo *nix, esto último que yo sepa no
hay forma (sin toquetear el kernel) de que ter permita hacer un flush
del buffer a /dev/null ... creo que a base de jugar con los parámetros
del modulo lp (si lo tienes como módulo), podrias ajustar el tamaño
del buffer de dispositivo. Ten en cuenta que si pones un valor muy
pequeño, podras *borrar* la cola y que casi no imprima nada mas que la
página en curso, pero te arriesgas a caer en la misma situación que
windows cuando está el sistema con carga alta, paradas repentinas de
la impresión por falta de información en el buffer.

 Yo creo que la solución mas elegante es echarle un ojo al cups a ver
si tiene alguna opción de modificación del buffer de dispositivo, para
que envie poca información.

 Me explico ...


 lpr archivo.ps ->> cups lo procesa con el gs y genera el RAW Stream
para la impresora ->> se encola para enviar al dispositivo ->> se abre
el dispositivo en modo escritura (esto ya activa ciertos buffers del
kernel) ->> se empieza a escribir en el dispositivo mientras no se
reciba una señal de cancelación o el dispositivo devuelva error
(buffer lleno, impresora parada, etc.).

 ->> Se recibe señal de cancelación ... >> Se deja de escribir en el
dispositivo, se escribe en el dispositivo la secuencia de fin de
pagina correspondiente al modelo y lenguaje que use ->> se hace un
flush del dispositivo para envia a la impr esta información.


 Ya a partir de aki depende de como la impresora maneje el tema de los
trabajos.

 El problema está en que no todas las impresoras tiene soporte
*nativo* para la gestión de trabajos, por ejemplo las hp usan el PLJ,
con lo que se le puede enviar una orden de cancelación en medio del
stream de datos y la impresora parará y cancelará el trabajo actual,
otras impresoras tienen un lenguaje nativo para hacer esto .. y otras
(las epson de gama media/baja por ejemplo y la mayoria de las impr de
tinta) simplemente no tienen este tipo de mecanismos y dejan esa
tarea al subsistema de impresión.

 Espero haberte clarificado el tema a tí y al resto de los listeros.

 Saludos


-- 
   _                                                                   _        
  // Raúl A. Betancort Santana    /> A Dream is an answer to      __   \\       
 // <rabs@dimension-virtual.com> // question that we don't know  (oo)   \\      
// Dimensión Virtual S.L.       //  how to ask.                 / \/ \  //      
\> A Linux Solution Provider   </                               `V__V' </       

Attachment: pgp3_tZSPXRIC.pgp
Description: PGP signature


Reply to: