Welche Wege und Umwege nimmt eine Datei, bis ihr Inhalt farbig oder schwarz auf weiß zu Papier gelangt?

Programme, die unter Linux druckbaren Output erzeugen möchten, kommen um die von Adobe entwickelte Seitenbeschreibungssprache PostScript nicht herum. Ihre Spezialität ist es, in einer eigenen Syntax all das exakt zu beschreiben, was als Grafik-Objekt auf einem Blatt Papier Platz findet – Linien, Bögen, Flächen, Punkte, Füllungen, Buchstaben in allen denkbaren Variationen. Fonts, Strichstärken, Farbtöne und -verläufe, Anordnung, Rotation, Skalierung, Verzerrung und viele andere Manipulationen der Darstellung sind machbar. PostScript kann sogar noch mehr als das: Es ist eine vollständige Programmiersprache, mit der sich notfalls die Zahl Pi berechnen, eine Festplatte formatieren oder eine Datei erzeugen lassen. Die neueste Version, PostScript 3, kann sogar “fremde” Formate wie JPEG oder TIFF in ihre Dateien einbetten.

Vorzeiten

Als PostScript 1985 auf den Markt kam, war das eine große Erleichterung für Anwendungsprogrammierer. Denn zuvor mussten sie für jede ihrer Applikationen und für jedes darin unterstützte Drucker-Modell einen eigenen Geräte-Treiber schreiben. Mit der neuen, zwischen Applikationen und Druckern angesiedelten PDL (“Page Description Language”) galt es nur noch, alles, was für die Darstellung auf Papier vorgesehen war, in dieser Sprache auszudrücken. Die Aufgabe, aus dem Format der Anwendung PostScript zu erzeugen, fiel einem “Treiberprogramm” zu. Die Druckerhersteller waren dafür verantwortlich, dass ihre Geräte die PostScript-Anweisungen richtig umsetzten.

Im Laufe der Zeit kamen weitere Grafik- oder Seitenbeschreibungssprachen als Konkurrenz dazu. Denn Adobe verlangte für PostScript-Interpreter in den Druckern Lizenzgebühren. Verschiedene Hersteller wollten diese einsparen und entwickelten eigene PDLs.

Die wichtigsten sind heute PCL (“Print Control Language”) von Hewlett-Packard, ESC/P (“Epson Standard Code for Printers”) und GDI (“Graphical Device Interface”) von Microsoft. Diese unterscheiden sich erheblich voneinander und sind weitgehend inkompatibel.

In professionellen Umgebungen (Desktop Publishing, PrePress und Publishing) ist PostScript nach wie vor unangefochten die Nummer Eins – genauso wie auf Linux-Systemen (obwohl gerade hier längst nicht das gesamte Potential von PostScript ausgeschöpft wird).

PostScript kann selbstverständlich auch “von Hand” programmiert werden. Listing 1 zeigt ein einfaches Beispiel. Wer es als Text-Datei abspeichert, kann es direkt an einen PostScript-fähigen Drucker schicken und ausdrucken. Am Bildschirm lässt sich die Datei mit verschiedenen PostScript-Viewern anschauen. gimp, ghostview oder gv sind dafür gleichermaßen geeignet. Zu sehen bekommt man (auf Bildschirm oder Papier) die Darstellung aus Abbildung 1.

Listing 1, grafisch dargestellt” width=”148″ height=”99″ /> Abbildung 1: Listing 1, grafisch dargestellt

%!PS            % Die ersten zwei Zeichen müssen immer '%!' sein.
 % zwei Vierecke % '%' leitet Kommentare ein. Der virtuelle
 100 100 moveto  % PS-Zeichenstift soll zur Koordinate (100,100)
 0 50 rlineto    % gehen, dann eine Linie 0 Einheiten nach rechts und
 50 0 rlineto    % 50 nach oben ziehen, weiter 50 nach rechts (0 nach
 0 -50 rlineto   % oben), zu guter Letzt 50 Einheiten senkrecht nach unten
 closepath       % und diesen "Pfad" schließen,
 .7 setgray      % als Farbton auf 70%-igen Grauwert schalten und
 fill            % das entstandene Viereck mit dieser Farbe füllen.
 %               % Das erstes Viereck ist fertig; die naechste Figur
 160 100 moveto  % wird auf analoge Weise konstruiert,
 0 60 rlineto    % allerdings mit z. T. "schiefen"
 45 10 rlineto   % Linien und mit einem dunkleren Grau gefüllt
 0 -40 rlineto   % (20% ist als PostScript-Farbwert
 closepath       % dunkler als 70%).
 .2 setgray      %
 fill            % Der abschließende Befehl "showpage" weist
 showpage        % den Drucker zum Seitenausstoß an.

Mit Zeilendruckern fing es an

Heutige Laserdrucker sind “Seitendrucker”: Sie setzen das komplette Bild einer Seite zuerst pixelweise als Bitmap komplett in ihrem Arbeitspeicher zusammen, bevor dieses zu Papier gebracht wird. Ihre “Eigenintelligenz” lässt sie sogar als selbstständige Knoten in TCP/IP-Netzen fungieren.

Frühere Drucker waren “Zeilendrucker”; daher auch der Begriff “Line Printer”. Grafik im heutigen Sinne war nicht druckbar, Drucker konnten nur Buchstaben und andere Zeichen wiedergeben und dabei maximal vier verschiedene Fonts benutzen. Seiten wurden Buchstabe für Buchstabe gedruckt (d. h., mechanisch auf das Medium gehämmert), wobei eine zickzackgefaltete Papierschlange aus einem Karton gezogen und durch den Drucker geführt wurde. Die Geräte waren direkt (meist über eine serielle Schnittstelle) am Host angeschlossen. “Netzwerk”-Drucken bedeutete, die Druckdatei von einem Host an einen anderen zu übertragen, damit dieser sie an einem bei ihm angeschlossenen Gerät ausgab.

Vom PostScript auf Platte zur Bitmap auf Papier

Was heutige Drucker auf Papier hinterlassen, ist lediglich eine bestimmte Anordnung von vielen (eventuell farbigen) Einzelpunkten. Wenn diese fein und dicht genug nebeneinander angeordnet sind, erscheinen sie dem menschlichen Auge als Linien, Flächen und Farbverläufe. Dieses Punktraster muss der Marking Engine eines Druckers fertig übergeben werden.

Die Druckdatei existiert anfangs als PostScript. Um aus diesen Anweisungen zum endgültigen Punktmuster für den Zieldrucker zu kommen, muss viel gerechnet werden. Dieser stark die CPU belastende Prozess wird RIP (“Raster Image Prozess”) genannt.

Echte PostScript-Drucker nehmen den PostScript-Code direkt entgegen. Für den Anwender am problemlosesten und zuverlässigsten, sorgen sie intern selbst für das “RIPen”. Vor ihr Druckwerk ist ein “Raster Image Prozessor” (ebenfalls RIP genannt) geschaltet, oft in Form eines Spezialchips. Dieser sorgt für die PostScript-Interpretation und erzeugt die Rasterdaten. Manche Hochleistungsdrucker nutzen einen eigenen Unix-Rechner, der ein Software-RIP beinhaltet, das als PostScript-Interpreter fungiert (Abbildung 2 links).

Abbildung 2: Dateikonvertierung und -übertragung bei PostScript- und Nicht-PostScript-Druckern

Das Software-RIP der Open-Source-Bewegung

Zum Ausdrucken auf PostScript-“ignoranten” Druckern ist mehr Aufwand nötig. Der PostScript-Code muss bereits auf dem Host-Rechner für die Marking Engine “vorverdaut” werden. Das unter Linux u. a. Unix-ähnlichen Systemen allgegenwärtige Ghostscript-Paket leistet bei dieser Präparierung unentbehrliche Dienste. Es fungiert hier sozusagen als Software-RIP, das gänzlich aus dem Zieldrucker heraus- und in den Client-Rechner vorverlagert wurde (Abbildung 2 rechts).

So unentbehrlich diese Software unter Linux ist – sie hat in ihrer “klassischen” Erscheinungsform einige gravierende Nachteile:

• Sie besteht aus zahllosen Einzelfiltern, deren Kommandozeilenoptionen oftmals undokumentiert oder sehr kryptisch sind.
• Die Ausgabe-Qualität ist auf manchen Druckern mehr als mangelhaft (kein Wunder, wenn die Hersteller keine Spezifikationen zur Verfügung stellen).
• Ihre Einzelfilter beruhen häufig auf den Beiträgen von Software-Entwicklern, die durch Reverse Engineering aufgrund eigener Bedürfnisse entstanden (weil sie Besitzer eines entsprechenden Druckers waren), jedoch zwischenzeitlich nicht mehr weitergepflegt werden.

Welche Ghostscript-Filter (auch “Treiber” genannt) installiert sind, erfahren Sie mit dem Kommando gs -h. Ghostscript antwortet mit einer Kurzinformation über seinen Gebrauch und zählt dabei alle Filter auf, die es kennt (auf meinem Rechner sind es 175!).

Magische Filter

Oft sollen Dateien gedruckt werden, die in einem Grafikformat (wie TIFF, GIF, JPEG, PDF, PNM, PNG, Sun Raster usw.) vorliegen. Nun gibt es zwar zahlreiche Tools und “Filter”, die daraus PostScript erzeugen können und sich per Kommandozeile bedienen lassen. Doch anschließend muss weiter konvertiert werden, nämlich mit einem Ghostscript-Filter ins Drucker-Format.

Da der manuelle Gebrauch von Ghostscript (und der Vor-Filter zum Erzeugen von PostScript) selbst vielen Kommandozeilen-Freaks bei Weitem zu umständlich ist, versuchen verschiedene Ansätze, diese Aufgabe zu vereinfachen. Am erfolgreichsten sind dabei die beiden Filterskripte apsfilter und magicfilter[7]. Diese führen zahllose Tools “unter einem Dach” zusammen. Sie erkennen automatisch das Format der Input-Datei, erzeugen daraus mit einem passenden Vor-Filter PostScript und generieren mit Hilfe von Ghostscript das Rasterformat für den Zieldrucker. Bei SuSE übernimmt APSfilter diese Koordinationsaufgabe, bei neueren Red-Hat-Ausgaben Magicfilter (früher rhs-printfilter). Auch Debian setzt auf Magicfilter.

Diese Filterkette funktioniert in der Regel sehr zuverlässig. Allerdings lässt sie den Anwender bei der Selektion gerätespezifischer Optionen (angefangen von der allereinfachsten Papierfachanwahl, gar nicht zu reden vom Lochen und Heften des Outputs) völlig im Stich.

Spulen und Drucken

Damit die konvertierten Druckdaten nicht mit anderen Druckjobs ins Gehege kommen, werden sie nicht etwa direkt an den Drucker, sondern an ein Druck- und Spool-System geschickt. Das ist verantwortlich für die geregelte Abwicklung aller Druckaufträge auf dem System.

Die dazu am häufigsten verwendete Software ist nach wie vor der BSD-Line-Printer-Daemon lpd (bei SuSE im Paket lprold enthalten). Ihm zugrunde liegt das rund 30 Jahre alte Protokoll LPR/LPD (“Line Printer Remote/Line Printer Daemon”) für das Drucken im Netzwerk.

Zeilendrucker waren Stand der Technik, als LPD zum Übertragungs- und Handhabungsprogramm für Druckdaten entwickelt wurde. Obwohl sich die zugrundeliegende Druck-Technik und auch der Umfang der Vernetzung gewaltig entwickelt hat, blieb das Basisprotokoll für Netzwerkdruck jahrzehntelang auf dem technischen Stand der Line-Printer-Ära stehen. Es leidet u. a. an mangelnden Authentifizierungsmöglichkeiten für die Nutzer, fehlender Verschlüsselung der Druckdaten und ungenügenden Übergabemöglichkeiten für Druckparameter.

Manche seiner Schwächen werden durch das neuere LPRng gemildert (bei SuSE eine Alternative, bei Red Hat Vorgabe), viele erst durch das moderne CUPS auf der Basis des IPP (“Internet Printing Protocol”).

Die Druckerdefinitionen beim klassischen LPR/LPD-Ansatz verstecken sich in einer Datei namens /etc/printcap. Dort schaut der LPD bei jedem neuen Print-Job nach, wie er ihn behandeln soll. Obwohl man sie wie jede ASCII-Konfigurationsdatei auch von Hand bearbeiten kann (vgl. [8]), wird sie meist von distributionseigenen Tools (YaST bei SuSE, printtool bei Red Hat) erstellt und gewartet. Diese erfragen bei einer Druckerinstallation einige Angaben wie Druckername, zu verwendender Filter (=Treiber) und Anschlussart. Daraus generieren sie einen fertigen printcap-Eintrag, bei dem auch der Aufruf des zuständigen Filterskripts erfolgt. SuSE- u. a. APSfilter-Benutzern steht zusätzlich ein Setup-Programm mit dem Namen SETUP in /var/lib/apsfilter zur Verfügung, das beim Anlegen der printcap-Einträge hilfreich zur Seite steht.

Wichtig ist der Drucker mit dem Namen lp, denn er wird automatisch als der systemweit gültige Standarddrucker angesehen und bekommt alle Aufträge, bei denen nicht ein anderer Drucker namentlich genannt ist.

Zu jedem logischen Drucker gehört ein eigenes Spool-Verzeichnis zum Zwischenlagern der Druckdateien und eine Gerätedatei (bei lokal angeschlossenen Geräten) bzw. die IP-Adresse (für Netzwerkdrucker), über die er angesprochen wird. Außerdem ist der zugehörige APS- oder Magicfilter-Input-Filter für jeden eingetragenen lokalen Drucker vermerkt.

Geräteabhängigkeiten

PostScript ist prinzipiell eine geräteunabhängige Sprache. Wenn es jedoch um das Ausdrucken auf einem konkreten Drucker geht, spielen immer geräteabhängige Features eine Rolle: Mit welcher Auflösung kann er arbeiten? Welche Finishing-Optionen stehen zur Verfügung? Welche Fonts sind druckerintern vorhanden?

Wie wir gesehen haben, war es bislang unter Linux ausgesprochen schwierig, gerätespezifische Funktionen auszureizen. Denn selbst wenn ein Ghostscript-Filter entsprechende Kommandozeilen-Parameter zur Verfügung stellt, sind diese meist zu unbekannt und in der Anwendung zu sperrig. Folglich werden selbst bei Druckern, deren integrierte Endverarbeitung mit Duplex- und Heftklammer-Einheit den Ausstoß fertig gebundener Hefte ermöglicht, von Linux aus in erster Linie einseitige “Lose-Blatt-Sammlungen” produziert.

Auch in der MacOS- oder Windows-Welt gibt es keinen gemeinsamen, verbindlichen Standard für die Definition gerätespezifischer Verarbeitungsoptionen. Obwohl seit PostScript Level 2 sogar ein “offizieller” Befehl für den Duplex-Druck existiert, muss kein Hersteller garantieren, dass sein Gerät diesen Befehl akzeptiert.

Trotzdem funktioniert “bei der Konkurrenz” der PostScript-Druck “mit allen Schikanen” bereits seit über zehn Jahren. Das Mittel zum Zweck ist genial einfach: eine modellgebundene PPD-Datei (“PostScript Printer Description”) im ASCII-Format beinhaltet alle gerätespezifischen Features mitsamt der zugehörigen Code-Sequenz, die zum Drucker geschickt werden muss, um die entsprechende Funktion abzurufen.

Der PostScript-Treiber liest die möglichen Optionen aus der PPD aus und bietet sie dem Nutzer im Druckdialog-Fenster zur Auswahl an. Der Basis-PostScript-Treiber des Betriebssystems lässt sich für jeden installierten Drucker mit der entsprechenden PPD “aufrüsten” und bietet dann die erweiterten Drucker-Features. Ist eine Auswahl getroffen, werden diese Job-Optionen als gerätespezifische Befehle in das geräteunabhängige PostScript eingefügt und abgeschickt. Ansonsten gelten für jeden Punkt bestimmte Default-Werte.

Mit CUPS (“Common UNIX Printing System”) erschließt sich diese Möglichkeit auch unter Linux. Der Administrator kann eine originale Hersteller-PPD, die mit dem Windows-Druckertreiber mitgeliefert wird, auf einen mit CUPS ausgestatteten Linux-Rechner kopieren.

Staunend stellen dann selbst langjährige Linuxianer fest, dass damit die Welt des Druckens vollständig im Zugriff ihrer grafischen Benutzeroberfläche liegt. Bedienoptionen verstecken sich nun nicht mehr unbemerkt in einer Manpage, sondern sind per Mausklick erreichbar. Der Zugang über die Kommandozeile bleibt dabei immer noch möglich, allerdings erheblich umfassender und zugleich einfacher als bisher.

CUPS wäre jedoch nur die Hälfte wert, wenn es sich auf PostScript-Drucker und deren Hersteller-PPDs beschränken würde. Der clevere Kunstgriff der CUPS-Entwickler ist folgender: Sie benutzen die neuerworbene Kenntnis der PPD-Syntax, um damit Beschreibungsdateien auch für Nicht-PostScript-Drucker zu erstellen.

Filter für CUPS

Auch CUPS verwendet für sein internes Software-RIP eine Code-Basis, die auf Ghostscript beruht. Allerdings haben die Entwickler an vielen ‘wüsten’ Stellen den ursprünglichen Ghostscript-Code modularisiert, gesäubert und aufgeräumt. Zudem verwendet CUPS einige wenige Filter mit “sprechenden” Namen, um den gesamten Funktionsreichtum von Ghostscript plus APS- bzw. Magicfilter nachzubilden und sogar zu übertreffen, bei gleichzeitig einfacherer Bedienung.

CUPS führt zur Erleichterung der Weiterverarbeitung ein eigenes, offengelegtes “CUPS-Raster”-Format ein. Als gemeinsames Ausgangsformat für die Erstellung des gerätespezifischen Rasterdatenstroms spielt es eine ähnliche Rolle wie die PDL als Bindeglied zwischen Applikationen und Druckern. CUPS-Raster wird von den Filtern pstoraster oder imagetoraster erzeugt und daraus das druckerspezifische Raster generiert.

Die CUPS-Filter-Architektur wurde von Anfang an modular gestaltet, mit dem Ziel, Dritte (auch kommerzielle Entwickler oder Druckerhersteller) auf einfache Weise ihre eigenen Filter ins CUPS-Framework einklinken zu lassen. Dies wird von Gimp-Print (siehe Kasten 1) bereits seit Längerem genutzt. Als einer der ersten Hersteller verwertet die Firma ZEDOnet diese Möglichkeit seit kurzem für ihr Produkt TurboPrint (siehe Seite 47). Mit Hilfe von Foomatic und CUPS-O-Matic[6] lassen sich auch existierende Ghostscript-Filter unverändert in CUPS einbinden.

Abbildung 3: Die Filterstruktur von CUPS

Abbildung 3 gibt eine Übersicht über die Architektur der CUPS-Filter. Rote Schrift auf gelbem Hintergrund zeigt die möglichen Eingabe-Formate für Druckdateien. Mit hellblauem Hintergrund sind die verschiedenen CUPS-Filter gekennzeichnet. Wenn keine “Filterung” sondern nur eine Datenübergabe stattfindet, ist der Hintergrund weiß. Raw Data sind bereits druckfertig und dürfen nicht mehr gefiltert werden. Ein Beispiel sind Druckdaten, die auf einem Windows-Client mit einem nativen Treiber erstellt und anschließend via Samba an CUPS zum Druck geschickt wurden. Dasselbe gilt für Bilder, die aus dem Print-Plugin des Gimp in Druck gegeben werden.

Wer sich das Diagramm genauer anschaut, stellt fest, dass an zentraler Stelle ein Filter namens pstops tätig ist, der offensichtlich nichts anderes tut, als PostScript nach PostScript zu wandeln. An dieser Stelle werden zwecks Accounting die Seiten gezählt, die CUPS verarbeitet. Außerdem sorgt pstops dafür, dass tatsächlich nur die Seiten der Datei zum Drucker geschickt werden, die im Auftrag stehen (beispielsweise 5-9, 11, 15, 22-25). Wenn mehrere Seiten auf ein Blatt gedruckt werden sollen, nimmt sich pstops auch dieser Aufgabe an.

Plug&Play

Als Linux-Heimanwender kann man mit CUPS auf einem alleinstehenden Rechner bereits wunschlos gücklich werden. Aber nicht nur der PPD-Trick bezüglich der Printer-Optionen macht CUPS so attraktiv. Der absolute Clou ist die komplette Netzwerktransparenz aller Grundfunktionen [1–3]. Das bedeutet, dass Filter, Treiber und Backends bei Konfiguration eines CUPS-Servers nicht mehr auf allen Arbeitsplatzrechnern einzeln eingerichtet und gepflegt werden müssen. Jeder Client, der frisch ans Netz gebracht wird, “findet” innerhalb von 30 Sekunden die verfügbaren Drucker, weil sie ihm vom Server per Broadcast in regelmäßigen Abständen mitgeteilt werden.

Der Client kann somit jeden Drucker sofort samt allen gerätespezifischen Optionen verwenden, ohne auch nur einen einzigen Filter oder Treiber lokal einzusetzen. Einfach Job-Optionen festlegen und das lokale PostScript (oder auch Text- und Grafikformate) per IPP an den Server schicken. CUPS-Rechner verwenden für den Datenaustausch untereinander automatisch dieses Protokoll. Der Server sorgt anschließend für die weitere Verarbeitung, nämlich Dateikonvertierungen, Spoolen und Weitergabe an den Zieldrucker über das entsprechende (eventuell noch “altmodische”) Drucker-Protokoll (LPR/LPD, HP JetDirect, …).