Von Kurt Pfeifle am Fr, 20. Oktober 2000 um 19:41 #
@ Dirk:
> Informationen zu CUPS und zum (kommerziellen) PrintPro findest Du im Internet unter www.danka.de --> die CUPS-FAQ mit ueber 100 Fragen (und noch nicht ganz so vielen Antworten ) ist unter http://www.danka.de/printpro/faq.html zu finden; ein CUPS Printing HOWTO ist in Arbeit.
@ Richard:
> das problem ist nicht das Spool System oder die Konfiguration, sonder die Qualität der der Treiber im vergleich zu den Windows
_B_e_i_d_e_s_ war bisher meist noch problematisch. Viele Features moderner Drucker waren unter Linux (in den trueben Prae-CUPS-Zeiten) fuer den Anwender unerreichbar. Gerade in der Office-Umgebung gibt es viele Drucker (meist PostScript) mit Duplex-Vorrichtungen, Sorterfaechern, Hefteinheiten usw.). Die zu konfigurieren war beinahe unmoeglich. Seit CUPS (und ESP PrintPro) ist das wirklich easy. Und wenn der Drucker PostScript kann, ist die Qualitaet in der Tat identisch mit den Windows-Pedanten. Die Netzwerk-Funktionalitaet von CUPS steckt dazuhin jeden MS-Pedanten locker in die Tasche: denn es erlaubt jedem CUPS-Client das Drucken _o_h_n_e_ Konfiguration (und laesst ausserdem noch LPD-, Samba-, und MacOS-Clients zu).
CUPS kann ausserdem ohne Zutun des Anwenders oder Administrators automatisch ueber einen Backup-Printserver drucken, sofern hier nur die Printer identisch konfiguriert sind (oder die Last verteilen)...
Wo sonst gibt es so was wie "Zero Administration for Clients", "Load Balancing" und "Automatic Failover Capacity" beim Drucken?
Auf dem Gebiet der Nicht-PostScript-Drucker kommt's dann tatsaechlich auf die "Treiber" an, wenn es um die Darstellungsqualitaet des Outputs geht. Linux-Anwendungen erzeugen meist eh' schon PostScript zu Druck-Zwecken. Damit dieses in Nicht-PS-Geraeten zu Papier gebracht wird, muss es zuerst durch einen "Raster Image Prozess" (RIP) interpretiert werden. Unter Linux erledigt dies meist ein "ghostscript-Filter", der das notwendige "RIP-pen" uebernimmt. Das Problem ist, dass sozusagen jedes Drucker-Modell sein eigenes Rasterformat (oder wenigstens eine eigene Abwandlung eines gaengigen Formats) verwendet. CUPS und ESP PrintPro haben in vielen Faellen bereits bessere Filter als das GNU-ghostscript -- aber leider manchmal halt noch in der Ausgabequalitaet im Vergleich zu MS Windows mehr oder weniger unterlegene. Hier koennten Hersteller wie HP (und fast alle anderen) viel tun, indem sie einfach gewisse Spezifikationen ihrer proprietaeren Rasterformate offenlegen (und wie man den Drucker ansteuern muss, um z.B. Tinten-Troepfchen verschiedener Groesse aufs Papier zu spritzen).
Rettung naht durch das "gimp-print"-Projekt. Dieses hat in den letzten Wochen enorme Fortschritte gemacht mit dem "stp"-Treiber, der Raster fuer eine Vielzahl von Druckermodellen ausgeben kann. (Entgegen des Namens ist die Nuetzlichkeit des Projekts nicht auf GIMP beschraenkt, sondern stp laesst sich als ghostscript-Filter in alle Druck- und Spoolsysteme integrieren, inkl. CUPS).
> Informationen zu CUPS und zum (kommerziellen) PrintPro findest Du im Internet unter www.danka.de
) ist unter http://www.danka.de/printpro/faq.html zu finden; ein CUPS Printing HOWTO ist in Arbeit.
--> die CUPS-FAQ mit ueber 100 Fragen (und noch nicht ganz so vielen Antworten
@ Richard:
> das problem ist nicht das Spool System oder die Konfiguration, sonder die Qualität der der Treiber im vergleich zu den Windows
_B_e_i_d_e_s_ war bisher meist noch problematisch. Viele Features moderner Drucker waren unter Linux (in den trueben Prae-CUPS-Zeiten) fuer den Anwender unerreichbar. Gerade in der Office-Umgebung gibt es viele Drucker (meist PostScript) mit Duplex-Vorrichtungen, Sorterfaechern, Hefteinheiten usw.). Die zu konfigurieren war beinahe unmoeglich. Seit CUPS (und ESP PrintPro) ist das wirklich easy. Und wenn der Drucker PostScript kann, ist die Qualitaet in der Tat identisch mit den Windows-Pedanten. Die Netzwerk-Funktionalitaet von CUPS steckt dazuhin jeden MS-Pedanten locker in die Tasche: denn es erlaubt jedem CUPS-Client das Drucken _o_h_n_e_ Konfiguration (und laesst ausserdem noch LPD-, Samba-, und MacOS-Clients zu).
CUPS kann ausserdem ohne Zutun des Anwenders oder Administrators automatisch ueber einen Backup-Printserver drucken, sofern hier nur die Printer identisch konfiguriert sind (oder die Last verteilen)...
Wo sonst gibt es so was wie "Zero Administration for Clients", "Load Balancing" und "Automatic Failover Capacity" beim Drucken?
Auf dem Gebiet der Nicht-PostScript-Drucker kommt's dann tatsaechlich auf die "Treiber" an, wenn es um die Darstellungsqualitaet des Outputs geht. Linux-Anwendungen erzeugen meist eh' schon PostScript zu Druck-Zwecken. Damit dieses in Nicht-PS-Geraeten zu Papier gebracht wird, muss es zuerst durch einen "Raster Image Prozess" (RIP) interpretiert werden. Unter Linux erledigt dies meist ein "ghostscript-Filter", der das notwendige "RIP-pen" uebernimmt. Das Problem ist, dass sozusagen jedes Drucker-Modell sein eigenes Rasterformat (oder wenigstens eine eigene Abwandlung eines gaengigen Formats) verwendet. CUPS und ESP PrintPro haben in vielen Faellen bereits bessere Filter als das GNU-ghostscript -- aber leider manchmal halt noch in der Ausgabequalitaet im Vergleich zu MS Windows mehr oder weniger unterlegene. Hier koennten Hersteller wie HP (und fast alle anderen) viel tun, indem sie einfach gewisse Spezifikationen ihrer proprietaeren Rasterformate offenlegen (und wie man den Drucker ansteuern muss, um z.B. Tinten-Troepfchen verschiedener Groesse aufs Papier zu spritzen).
Rettung naht durch das "gimp-print"-Projekt. Dieses hat in den letzten Wochen enorme Fortschritte gemacht mit dem "stp"-Treiber, der Raster fuer eine Vielzahl von Druckermodellen ausgeben kann. (Entgegen des Namens ist die Nuetzlichkeit des Projekts nicht auf GIMP beschraenkt, sondern stp laesst sich als ghostscript-Filter in alle Druck- und Spoolsysteme integrieren, inkl. CUPS).