Si uso CUPS, ¿deberían los clientes tener controladores instalados localmente?
Ejemplo: digamos que tenemos 1 PC en red con Linux, 1 servidor de impresión (o CUPS, servidor de impresión Samba)
Si la PC con Linux desea imprimir un documento a través del servidor de impresión, ¿se requiere que la PC con Linux tenga los controladores para la impresora que va a utilizar?
¿O utiliza alguna API genérica?
Respuestas:
El servidor de impresión que ejecuta CUPS es la única máquina que necesita tener los controladores. Lea sobre CUPS en Wikipedia, por ejemplo: en la sección Descripción general , esto lo dice claramente:
De lo contrario, ¿cuál sería el beneficio real de ejecutar CUPS?
fuente
Si está utilizando Samba / CUPS como servidor de impresión para clientes basados en Windows, los clientes normalmente tendrán controladores para esa impresora, aunque en algunos casos CUPS puede hacer su propia traducción. Por ejemplo, es posible configurar ghostscript y renderizar postscript para mostrar en una impresora que no sea PS, aunque los clientes de Windows necesitarían un controlador PS que funcione bien con esto.
Para los clientes de Linux, la respuesta es: es complicado pero no. Unix / Linux tradicional no tiene una API nativa estándar de impresión o representación equivalente a la GDI de Windows, aunque las bibliotecas como Cairo pueden proporcionar esta funcionalidad para las aplicaciones que las utilizan. La mayoría de las aplicaciones tradicionales de Unix simplemente imprimen ASCII para generar o generar archivos Postscript de forma nativa. Las bibliotecas de renderizado independientes del dispositivo, como Cairo, simplemente renderizarán a Postscript a través de su propio controlador, que se incluiría en el cliente con la biblioteca.
Es casi seguro que encontrará Postscript en algún lugar del flujo de trabajo para un CUPS o un sistema de impresión lpr / lpd anterior. Por lo general, los clientes producirán salida ASCII o Postscript. La salida ASCII se convertirá a través de algo como a2ps y Postscript que acaba de pasar. El PostScript se pasará a la impresora o una capa de representación basada en Ghostscript.
Ha pasado un tiempo desde que configuré un subsistema de impresión basado en Linux, pero IIRC los controladores de PS son bastante genéricos con solo un archivo PPD para la impresora de destino. Los clientes no necesariamente necesitan saber mucho al respecto. Tradicionalmente, solo configura las colas para imprimir de diferentes maneras (por ejemplo, dúplex, no dúplex o membrete) y se convierten en destinos de impresión separados.
Si está utilizando aplicaciones con control de impresora local, por ejemplo, aplicaciones que utilizan la API de GNOME-Print , o imprimiendo archivos directamente con
lpr -oopciones, la instalación de impresión puede ejercer más control sobre el destino real de la impresora. Por ejemplo, se pueden seleccionar bandejas particulares u opciones de dúplex. Si tiene un archivo PPD correcto para la impresora instalada en el servidor CUPS, estas opciones deberían funcionar desde el cliente sin requerir que el cliente tenga instalado un controlador adicional.EDITAR: en su caso, creo que el problema podría ser que el LBP810 es un winprinter y nunca se produjeron controladores de Linux para él. Su mejor opción podría ser obtener una impresora diferente, lo que se puede hacer de manera muy económica si se enfoca correctamente.
Las impresoras láser de segunda mano son muy baratas en Ebay, y puede obtener una Laserjet 4100 o algo similar por unos 100 USD , dependiendo de su ubicación. Todos los láseres HP de rango medio son compatibles con Postscript o PCL5 / 6 y funcionan muy bien con Linux y CUPS. Debería tener pocos problemas para que uno de estos funcione y los usados son tan baratos que puede tratarlos como un artículo desechable.
fuente