Verschlungene Pfade

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.