El Wed, Jan 02, 2002 at 05:45:58AM -0300, Santiago Pastorino escribió: > A lo que dice el subject quisiera agregarle que me resulta malo el > sistema de impresión que tenemos en linux y voy a explicar porque, > aunque seguramente el problema no sea el sistema de impresión y sea yo > que no lo sé usar, pero bueh, ojalá sea yo porque los problemas que > tengo me tienen harto. Esto huele a *uso inadecuado* o mas bien a *vicios de modo de uso Windozero* ... ;) > El asunto es que tengo una Epson Stylus 400 la tenía bien configurada, > con lpr, usando los filtros de magicfilter, pero tenía dos grandes > problemas, uno era cuando quería cancelar una impresión, corría lprm > para borrar la cola, la cola se borraba bárbaro pero la impresora seguía > queriendo imprimir no se que cosa ya que cuando borro la cola no hay más > nada que imprimir, tenía que apagar la impresora y volverla a prender > para que se dejara de joder, yo no sé de repente ese es el > funcionamiento normal pero creo que no debería ser así, en windows le > das cancelar y chau, no imprime más. Es el comportamiento normal ... te explico: tu mandas a imprimir algo ... : lpr archivo.ps eso pasa al subsistema de impresión que comienza (con el lpr clásico y la versión lprng) por identificar el tipo de fichero y procesarlo para pasarlo al formato nativo de la impresora (PS,PCL,RAW Bitmaping,etc.), luego se pasa al spooler, que lo encola para enviar al dispositivo (u a otro servidor de impresión si es una impresora de red), y luego se empieza a enviar al dispositivo físico. En esta última etapa se empieza a enviar el archivo procesado en codigo nativo al lp0,usb0 o donde tengas pinchada la impresora, resulta que todos los *nix manejan los dispositivos de caracteres (el mensaje se puede alargar mucho si me pongo a explicar que es esto) a base de buffers, con lo que aunque el lpq te diga que ya ha *terminado* de enviar el archivo, posiblemente aún quede alguna información en el buffer del dispositivo o incluso en el propio buffer de la impresora (las impresoras postcript suelen tener varios Mg de buffer). Esto es lo que hace que aún cuando has *vaciado* la cola de impresión, es muy probable que aún quede información en el buffer del dispositivo *nix o en el propio de la impresora, con lo que la cola está *vacia* pero er bicho sige escupiendo papel. En Windows no ocurre esto, porque windows no maneja *buffers* para dispositivos como las impresoras, o mas bien maneja buffers muy *cortos*, el ejemplo clarificador es que si estas imprimiendo en windows al mismo tiempo que le estas dando *caña* al disco duro, veras que la impresora se *para* a esperar que windows tenga tiempo de leer otra *porción* del archivo raw para enviarlo a la impresora; Este misma situacion no se produce con tanta *facilidad* en *nix. > El otro drama era cuando estaba imprimiendo y apagaba la impresora, al > prenderla en vez de imprimir lo que le faltaba empieza a imprimir > cualquier divague, esto tampoco sé como es el funcionamiento normal pero > seguro que este no puede ser, tenía que nuevamente borrar la cola y > apagar (totalmente molesto y más aún si se piensa en una red grande > donde mucha gente manda cosas a imprimir por hay se quiere cancelar un > trabajo y hay que cancelar todo lo demás debido a este comportamiento > tan raro. Esto tambien tiene una explicación simple basada en lo anterior que te he comentado... Veamos: Si estas enviando información a la impresora y la apagas, se borra el buffer de la impresora (la has apagado y su circuiteria pierde toda información), pero no así el buffer del dispositivo *nix, ni tampoco la cola, para el sistema simplemente la impresora no responde. Si haces eso mismo con windows, te pasará exactamente igual. Al volverla a encender, el sistema empieza otra vez a enviar la información que le queda a la impresora, pero claro esa información ya no es completa, no contiene los comandos de inicialización del dispositivo, colocación de cabezales,etc. Es por eso que la impresora empieza a imprimir *basura*, en realidad lo que imprime es la representación ASCII de la información que le llega, y lo hará hasta que reconozca un comando de *impresión* nativo, lo cual, dependiendo del modelo de impresora (sobre todo con las winprinters) puede no volver a suceder en todo el stream de datos que le queda por enviar. > Después me enteré que lprng era una evolución de lpr y que es mejor y no > se que no se cuanto, saqué lpr, puse lprng, tuve los mismos problemas y > más todavía, no le vi ninguna cosa en la que funcionase mejor. El lprng es (que yo sepa), una mejora del lpr de *BSD clásico en cuestiones de seguridad y manejo de la cola y filtros. > Ahora me enteré que Cups es el mejor sistema de impresión que existe, > que en un futuro se pretende que sea el más usado en linux, etc, etc, lo > instalé, y a los problemas que tuve con los sistemas anteriores se me > agregaron otros, ahora si corro lpr archivo.pdf no imprime nada, toma > una hoja la hace pasar y sale vacía, y toma otra y otra, los pdf > solamente los puedo imprimir con acroread, esto pensé que podría ser por > el tema de los filtros pero pensé que Cups no precisaba esto o que ya > los > traía, leí documentación a patadas y no encontré nada, leí un articulo > que hay sobre Cups en linuxprinting y me parece que el chino antiguo es > más claro que ese articulo, y lo peor no ha llegado, con Cups si quiero > cancelar algo que se este imprimiendo tengo que borrar la cola, apagar > la impresora una vez (hasta ahí igual que lpr y lprng) la prendo y sigue > jodiendo, vuelvo a apagar, prendo y sigue intentando imprimir bolazos, > apago por tercera vez y cuando prendo recién ahí no jode más. > Bueno, se aceptan recomendaciones, donde buscar información clara, la > cual no encontré, soluciones, puteadas, etc. El tema está en que cups no hace un *preproceso* del archivo, cups entiende basicamente 2 tipos de archivos, texto ASCII puro y arhivos .ps, se puede hacer un *mejunje* entre lpr/ng standar y cups para que lpr preprocese los archivos y cups se encarge de la fases de encolado, ripping e impresión. CUPS es un subsistema de impresión simplemente FANTASTICO, administrar una red hetereogenea con dispositivos de impresión variados, conectados a distintos sistema operativos o dispositivos de impresión independientes, en redes remotas, con balanceo de carga entre dispositivos, colas redundantes, etc. ... y todo eso integrable con SAMBA,NetTalk,IPP,TCP/IP directo, etc. Manejando todo desde un interfaz Web, o integrarlo en tu sistema de gestión global favorito ... eso, eso ... es simplemente genial. Ademas funciona desde un equipo con necesidades de impresión simples (pc casero con impresora) hasta una macrored de una corporación. Con respecto a tu problema con cups ... seria mejor que le echases un ojo al manual que incorpora, tanto al de administrador como al de usuario. Si quieres usarlo con equipos windows integralo a traves de SAMBA, podras gestionar las colas igual que cualquier otra cola de un windows. Todo está muy,muy bien explicado en el manual del CUPS, te recomiendo le eches un ojo a http://localhost:631 , donde tengas el cups instaldo .. ;) 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:
pgpAsjwJnvH9j.pgp
Description: PGP signature