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 __ \\ // <[EMAIL PROTECTED]> // question that we don't know (oo) \\ // Dimensi�n Virtual S.L. // how to ask. / \/ \ // \> A Linux Solution Provider </ `V__V' </
pgpoo3R45aVfb.pgp
Description: PGP signature
