Dieses Kapitel soll Ihnen den theoretischen Hintergrund des Druckens im Allgemeinen und des Druckens mit ∪︀ im Speziellen vermitteln. Wenn Sie diese Informationen nicht benötigen, können Sie hier zum nächsten Kapitel weiterspringen. Manchmal benötigt man jedoch etwas zusätzliche Theorie, um praktische Probleme lösen zu können. Dann sollten Sie auf dieses Kapitel zurückkommen. Drucken ist eines der komplizierteren Kapitel in der IT-Technik. Früher war es so, dass jeder Entwickler eines Programms, das Druckdaten ausgeben sollte, einen eigenen Druckertreiber schreiben musste. Dies war ziemlich kompliziert, da verschiedene Programme verschiedene Dateiformate benutzten. Sogar Programme mit demselben Zweck, wie &zb; Textverarbeitungen, konnten häufig die Formate anderer Textverarbeitungen nicht lesen. Es gab keine einheitliche Schnittstelle, was dazu führte, dass Programmierer oft nur einige wenige ausgewählte Druckmodelle unterstützten. Für ein neu auf dem Markt erscheinendes Gerät mussten die Programmautoren einen neuen Treiber schreiben, wenn sie wollten, dass ihr Programm das Gerät unterstützt. Für die Hersteller wiederum war es unmöglich sicherzustellen, dass ihr Gerät von jedem in der Welt bekannten Programm unterstützt wurde (obwohl es viel weniger Programme gab als heute). Bei zehn zu unterstützenden Anwendungen und einem Dutzend Druckern bedeutete das für den Systemverwalter den Umgang mit 120 Treibern. Dadurch wurde die Entwicklung einer einheitlichen Schnittstelle zwischen Programmen und Druckern dringend notwendig. Das Auftauchen von Page Description Languages (Seitenbeschreibungsprachen), die die graphische Ausgabe von Tinte und Toner auf Papier (oder auf anderen Ausgabemedien wie Bildschirmen, Photogeräten &etc;) in einheitlichen Weise beschrieben, war ein Schritt, der eine große Lücke schloss. Eine dieser Entwicklungen war &PostScript; von Adobe. Dies bedeutete, ein Anwendungsprogrammierer konnte sich nun darauf konzentrieren, eine Beschreibung seiner zu druckenden Seite in der Sprache &PostScript; zu erstellen. Währenddessen konnten sich die Entwickler von Druckgeräten darauf konzentrieren Ihre Geräte &PostScript;-fähig zu machen. Natürlich wurden mit der Zeit noch andere Beschreibungsarten entwickelt. Die wichtigsten Konkurrenten von &PostScript; waren PCL (Print Control Language, von &Hewlett-Packard;), ESC/P (von Epson) und GDI (Graphical Device Interface von &Microsoft;). Das Erscheinen dieser Sprachen zur Beschreibung von Druckseiten machte das Leben leichter und beschleunigte die weitere Entwicklung für alle. Trotzdem gibt es immer noch unterschiedliche, inkompatible und konkurrierende Beschreibungssprachen, die das Leben für Benutzer, Administratoren, Entwickler und Hersteller schwer genug machen. &PostScript; wird meistens in professionellen Druckumgebungen wie PrePress und in der Druckindustrie eingesetzt. Im &UNIX;- und &Linux;-Bereich hat &PostScript; eine Vormachtstellung unter den Beschreibungssprachen (PDLs). Dort erzeugt fast jedes Programm ein &PostScript;-Abbild seiner Seiten, wenn Sie den Knopf Drucken betätigen. Hier sehen Sie nun ein einfaches Beispiel eines handgemachten &PostScript;-Codes, das zwei einfache Zeichnungen beschreibt: %!PS 100 100 moveto 0 50 rlineto 50 0 rlineto 0 -50 rlineto closepath .7 setgray fill % first box over; next 160 100 moveto 0 60 rlineto 45 10 rlineto 0 -40 rlineto closepath .2 setgray fill Hiermit wird der imaginäre &PostScript;-Stift angewiesen, eine Figur in einer bestimmten Weise zu zeichnen und diese dann mit verschiedenen Grauschattierungen zu füllen. Der erste Teil könnte ausführlicher übersetzt folgendermaßen lauten: Gehe zu den Koordinaten (100, 100), ziehe eine Linie mit einer Länge von 50 nach oben, dann eine von dort nach rechts, dann wieder runter und schließe dann die Figur. Nehme jetzt eine Farbe mit 50% Grauanteil und benutze diese, um die Figur zu füllen. Das Beispiel als Bild dargestellt. Natürlich kann &PostScript; viel kompliziertere Dinge als dieses einfache Beispiel. Es ist eine voll ausgestattete Programmiersprache mit vielen verschiedenen Operatoren und Funktionen. Sie können &PostScript; sogar dazu benutzen, den Wert von Pi zu berechnen, Ihre Festplatte zu formatieren oder um in eine Datei zu schreiben. Die wirkliche Stärke von &PostScript; ist allerdings die Beschreibung der Anordnung graphischer Objekte auf einer Seite. Zusätzlich beherrscht &PostScript; alles, was Sie sich auf einem Blatt Papier vorstellen können, wie Buchstaben in verschiedenen Schriftarten, Figuren, Formen, Schatten, Farben, Linien, Punkte und Raster, skalieren, verschieben, umwandeln, drehen und rastern ... Eine &PostScript;-Datei ist ein ziemlich abstraktes Abbild einer oder mehrerer zu druckender Seiten. Idealerweise sollte die Datei die Seiten geräteunabhängig beschreiben. &PostScript; ist normalerweise nicht sichtbar und befindet sich nur auf der Festplatte oder im Arbeitsspeicher. Das, was Sie normalerweise auf einem Blatt Papier sehen, ist fast immer ein Rasterbild. Auch wenn Ihnen Ihr Gehirn sagt, dies sei eine Linie, werden Sie mit einer stark vergrößernden Lupe die kleinen Punkte auf dem Papier erkennen. Eine Ausnahme hiervon sind die so genannten Plotter, die mit einem Stift arbeiten. Einfache Punkte in verschiedenen Farben sind das Einzige, was Drucker heutzutage auf Papier ausgeben können. Diese Punkte können sich in der Größe unterscheiden, was dann zu verschiedenen Auflösungen führt. Die komplette Seite besteht jedoch nur aus Punkten. Für die verschiedenen Drucker müssen die Rasterbilder unterschiedlich verarbeitet werden. Ein Tintenstrahldrucker hat abhängig von seiner Auflösung, der Anzahl der Tintenpatronen (sehr gute Drucker brauchen sieben verschiedene Tinten, während billigere Modelle manchmal nur 3 haben), der Anzahl der Düsen (einige Drucker haben mehr als 100!), des benutzten Mischungsalgorithmus und vielen anderen Dingen ein Endraster-Format und eine Transferreihenfolge, die stark vom genauen Modell abhängt. Früher, zu Zeiten des LPD, waren Drucker Maschinen, die unzählige Zeilen von ASCII-Text auf Endlospapier hämmerten, das sich in zickzackförmigen Schlangen aus einem Karton unter dem Druckertisch hervorwand. Ein gewaltiger Unterschied im Vergleich zu heute. Bevor die fertigen Rasterbilder auf dem Papier ausgegeben werden, müssen sie zuerst aus den abstrakten &PostScript;-Vorlagen berechnet werden. Dieser berechnungsintensive Schritt wird Raster Imaging Process (RIP) genannt. Bei &PostScript; wird der RIP-Schritt von den Geräten selbst durchgeführt. Die &PostScript;-Datei wird einfach an den Drucker gesendet. Der Raster Imaging Processor (auch RIP genannt) im Drucker ist für die weitere Verarbeitung der &PostScript;-Seite und der Ausgabe des Rasterbildes auf Papier verantwortlich. Da er ein spezialisierter Prozessor ist, erfüllt er diese Aufgabe sehr gut. Kleinere &PostScript;-Geräte haben einen auf einem Chip eingebauten Hardware-RIP. Große, professionelle Drucker haben oft einen Software-RIP, der auf einem extra bereitgestellten &UNIX;-Rechner läuft. Hierfür werden oft Sun SPARC Solaris oder &SGI; &IRIX; Maschinen eingesetzt. Was aber tun, wenn Sie keinen &PostScript;-Drucker besitzen? Der RIP-Schritt muss ausgeführt werden, bevor die Daten an die Druckeinheit weitergegeben werden. Die &PostScript;-Daten Ihrer Anwendung müssen also auf Ihrer eigenen Maschine berechnet werden. Dazu muss das genauer Rasterformat des Zieldruckers erstellt werden. Dadurch, dass der Drucker &PostScript; nicht selbst verarbeiten kann, wird die ganze Sache etwas komplizierter. Es wird eine Software benötigt, die diedamit verbundenen Aufgaben lösen kann. Genau dies erledigt das für viele &Linux;-, *BSD- und andere &UNIX;-Systeme verfügbare Softwarepaket &ghostscript;. &ghostscript; ist ein &PostScript;-Interpreter, ein Software-RIP für viele verschiedene Geräte. Um Rasterbilder aus &PostScript;-Daten zu erzeugen, benutzt &ghostscript; das Filterkonzept. Es gibt viele Filter in &ghostscript;, von denen einige auf bestimmte Drucker spezialisiert sind. &ghostscript;-Filter für bestimmte Geräte wurden oftmals ohne die Unterstützung des Herstellers entwickelt. Ohne die Spezifikationen und ohne technische Dokumente war es ein sehr mühsamer Weg die Protokolle und Datenformate zu entschlüsseln. Nicht alle &ghostscript;-Filter arbeiten gleich gut mit ihren Druckern. Es gibt jedoch einige neuere Filter wie den stp-Filter des Gimp-Print-Projekts, die sehr gute Ergebnisse bis hin zu Fotoqualität liefern. Diese Filter sind ihren Gegenstücken unter &Microsoft; &Windows; ebenbürtig oder übertreffen diese Treiber sogar noch. Die meisten Programme in &UNIX;- und &Linux;-Systemen erzeugen &PostScript;-Daten als Druckausgabe. Die Filter sind die eigentlichen Arbeitstiere in den Drucksystemen. Sie erzeugen aus jeder &PostScript;-Eingabe die richtigen Rasterbilder für Zielmaschinen ohne &PostScript;-Unterstützung. ∪︀ benutzt eigene Filter, die jedoch auf dem Filtersystem von &ghostscript; basieren. Der pstoraster- und der imagetoraster-Filter sind direkt vom &ghostscript;-Quelltext abgeleitet. Unter ∪︀ wurden die Abläufe des alten Codes neu organisiert und in unterschiedliche und klar zugeordnete Module aufgeteilt. Die nächste Zeichnung (mit Hilfe von &kivio; erstellt) zeigt einen Überblick über die Filter und Backends in ∪︀ und wie diese zusammenpassen. Der Ablauf ist von oben nach unten dargestellt. Backends sind spezielle Filter, die keine Daten in verschiedene Formate konvertieren sondern die fertigen Dateien an den Drucker schicken. Es gibt verschiedene Backends für die unterschiedlichen Übertragungsprotokolle. Gestarteter &kprinter;-Dialog (&kivio; Entwurf) Gestarteter &kprinter;-Dialog (&kivio; Entwurf) Neben dem aufwendigen Filterteil zum Erstellen eines Rasterbildes braucht jede Drucksoftware einen Warteschlangen-Mechanismus. Dieser kümmert sich darum, dass verschiedene Druckaufträge von verschiedenen Benutzern den richtigen Druckern und Filtern zugewiesen werden. Der Warteschlangen-Mechanismus ist Teil des Druckdämons. Dieser Dämon sorgt für Ordnung im System. Er ist auch für die Kontrolle von Druckaufträgen zuständig, so dass Benutzer die Möglichkeit haben, ihre eigenen Druckaufträge abzubrechen, anzuhalten, erneut zu starten &etc;. Jetzt, da Sie wissen, wie eine &PostScript;-Datei (die die Anordnung der Seitenelemente in einer sehr geräteunabhängigen Weise beschreibt), in ein Rasterbild umgeandelt wird, werden Sie sich vielleicht folgendes fragen: Wie kommen diese ganzen unterschiedlichen Auflösungen, Papiergrößen, Farben und Filter auf meinem Drucker genau richtig raus? Wie paßt das in das Modell des geräteunabhängigen &PostScript;? Die Antwort sind die so genannten &PostScript;-Druckerbeschreibungsdateien (&PostScript; Printer Description, &PPD;). Eine &PPD;-Datei beschreibt alle geräteabhängigen Eigenschaften. Außerdem enthält die Datei die Befehle, mit denen bestimmte Eigenschaften des Geräts angesprochen werden. Trotzdem bestehen &PPD;-Dateien nur aus einfachem ASCII-Text. &PPD;-Dateien wurden von Adobe erfunden, um den Herstellern die Implementierung neuer Eigenschaften in &PostScript;-Druckern so einfach wie möglich zu machen und dies auf einem standardisierte Weise. &PPD;-Dateien sind von Adobe gut beschrieben und dokumentiert. Ihre Spezifikation ist praktisch ein offener Standard. Drucken mit &PostScript; wurde ursprünglich nur für &Microsoft; &Windows;- und Apple &Mac;-Systeme entwickelt. Über einen langen Zeitraum hinweg war das Drucken auf modernen Geräten auf &Linux;- und &UNIX;-Systemen nicht möglich. Jetzt können jedoch bestehende &PPD;-Dateien von allen Systemen voll ausgeschöpft werden, die ∪︀ benutzen. Über &PPD;-Dateien konnten Druckerhersteller geräteabhängige Hardware-Eigentschaften wie Duplex-Modi, Sortierung, Lochen &etc; einbauen. Der Druckertreiber lädt die &PPD;-Datei einfach als zusätzliche Konfigurationsdatei. Dadurch erfährt der Treiber von den verfügbaren Optionen des Gerätes und wie diese Optionen angesteuert werden. Zusätzlich werden die neuen Optionen in der graphischen Oberfläche angezeigt. Durch diesen Mechanismus sind Sie in der Lage geräteunabhängige &PostScript;-Dateien zu drucken, denen vor dem Ausdruck geräteabhängige Optionen hinzugefügt werden. Ursprünglich wurden &PPD;-Dateien in &UNIX;- und &Linux;-Systemen nicht benutzt. Die Hersteller der &PPD;s hatten nie beabsichtigt, diese Dateien auf anderen als den ursprünglich unterstützten Betriebssystemen (&Microsoft; &Windows; und &MacOS;) einzusetzen. Durch den brillanten Schachzug von ∪︀, die &PPD;-Spezifikation voll zu unterstützen, haben Sie jetzt die Möglichkeit alle Eigenschaften moderner Drucker unter &Linux; und &Linux;-ähnlichen Systemen zu nutzen. &kdeprint; macht die Benutzung von ∪︀ sogar noch einfacher als es sich die ∪︀-Entwickler je erträumt hätten. Wenn Sie einen &PostScript;-Drucker besitzen, kann ∪︀ die vom Hersteller bereitgestellten &PPD;-Dateien für &Windows; verwenden. Die Dateien kosten normalerweise kein Geld und können einfach von einem &Windows;-Computer mit installiertem &PostScript;-Treiber des entsprechenden Modells kopiert werden. Alternativ dazu finden Sie &PPD;-Dateien auch auf den zu Ihrem Drucker mitgelieferten Medien oder an verschiedenen Stellen im Internet. Jetzt wissen Sie wie &PostScript;-Drucker &PPD;s benutzen können. Aber wie sieht es mit nicht-&PostScript;-Druckern aus? ∪︀ bedient sich dazu eines raffinierten Kunstgriffs: Indem es dasselbe Format und dieselbe Datenstruktur wie die &PPD;s der &PostScript;-Welt verwendet, kann ∪︀ die verfügbaren Druckoptionen für nicht-&PostScript;-Drucker genauso beschreiben wie für echte &PostScript;-Drucker. Für einige spezielle Anforderungen von ∪︀ wurden einfach einige wenige Optionen hinzugefügt, &zb; die Zeile, die angibt, welcher Filter die &PostScript;-Datei weiter verarbeitet. Damit konnten die Entwickler die gleiche Software benutzen um die &PPD;s nach verfügbaren Optionen zu durchsuchen. Natürlich konnten sich die ∪︀-Entwickler nicht darauf verlassen, dass die Hersteller der nicht-&PostScript;-fähigen Drucker sofort damit beginnen würden, für diese &PPD;s zu entwicken. Diesen schwierigen Start mussten sie alleine bewältigen, indem sie die &PPD;s von Grund auf neu schrieben. Mehr als 1000 dieser &PPD;s sind in der kommerziellen Version von ∪︀ enthalten, die unter dem Namen ESP PrintPro verkauft wird. Inzwischen sind eine Menge &PPD;s für ∪︀ verfügbar, die aber meistens immer noch nicht von den Druckerherstellern stammen sondern von freien Softwareentwicklern. Die ∪︀-Leute bewiesen, dass es funktioniert und andere folgten schnell: Vor ein bis zwei Jahren war das Drucken unter &Linux; und &UNIX; noch eine Flickschusterei; jetzt wird eine große Fülle von Druckern unterstützt, darunter 7-farbige Tintenstrahldrucker die Ausgaben in Photoqualität ermöglichen. Sie können &PPD;s zur Benutzung von ∪︀ mit nicht-&PostScript;-Druckern von verschiedenen Quellen im Internet beziehen: zunächst wäre da www.linuxprinting.org, wo sie online eine CUPS-O-Matic-&PPD; für jeden Drucker erzeugen können, der schon früher von &ghostscript; unterstützt wurde. So können Sie ohne größeren Aufwand auf ∪︀ umsteigen. Falls Ihr Drucker schon mit &ghostscript; gut funktionierte, können sie CUPS-O-Matic benutzen, um den Treiber ins ∪︀-System zu integrieren und so die beste Lösung aus beiden Welten zu bekommen. zweitens gibt es ∪︀-&PPD;s für mehr als 120 Druckermodell, die durch den neuen universellen stp-Treiber unterstützt werden. stp war ursprünglich die Abkürzung für Stylus Photo, und wird nun vom Projekt gimp-print weiterentwickelt. Ins Leben gerufen wurde das Projekt von Mike Sweet, dem führenden ∪︀-Entwickler. Die Homepage des Projekts finden Sie unter gimp-print.sourceforge.net. Dieser Treiber liefert auf vielen modernen Tintenstrahldruckern Ausdrucke in Photoqualität. &HP; Laser- und DeskJet, Epson Stylus und Photo Color Modelle werden genauso unterstützt wie einige Modelle vonCanon und Lexmark. drittens gibt es die kommerzielle Erweiterung von ∪︀, die von den ∪︀-Entwicklern selbst erstellt wurde. Die Erweiterung heißt ESP PrintPro und enthält mehr als 2300 Druckertreiber. Außerdem liegen verbesserte imagetoraster- und pstoraster-Filter bei. ∪︀ ermöglicht den Herstellern die Unterstützung ihrer Druckermodelle unter &Linux; und &UNIX; zu vergleichsweise niedrigen Kosten. Der modulare Aufbau von ∪︀ ermöglicht das Einbinden von Filtern (=Treiber) mit minimalem Aufwand und erlaubt den vollständigen Zugriff auf das Drucksystem, das CUPS; zur Verfügung stellt. Lesen Sie mehr über die ∪︀-Funktionen in der verfügbaren ∪︀-Dokumentation unter http://www.cups.org/documentation.html und http://www.danka.de/printpro/faq.html. Desweiteren gibt es unter http://www.linuxprinting.org/ eine große Sammlung zu allen Themen, die mit Drucken unter &Linux; und &UNIX; zu tun haben. Über einen langen Zeitraum hinweg waren viele Entwickler mit dem guten alten LPD unzufrieden. Es gab einige neue Projekte, die gegründet wurden, um das Drucken zu verbessern. LPRng ist wohl das bekannteste Beispiel. Andere sind: PDQ, PPR, PLP, GNUlpr und RLPR. Keines dieser Programme stellte jedoch einen echten Durchbruch dar. Die meisten erweiterten nur die alten LPD Spezifikationen mit wenigen (oder vielen) Zusätzen, so dass die Programme inkompatibel zueinander wurden. Nachdem Grant Taylor, der Autor des Linux Printing HOWTO Dokuments, die Entwicklung der verschiedenen BSD-artigen Alternativen verfolgt hatte, kam er schließlich in seinem Feldzug zur Abschaffung des LPD. zu der Erkenntnis: LPD muss weg! Seitens der Industrie wurden ebenfalls Anstrengungen unternommen die wohlbekannten Schwächen des LPD zu beseitigen. Es begann mit proprietären Erweiterungen des alten LPD und führte dann zum Versuch von &Hewlett-Packard;, &HP; JetDirect als neues Netzwerk-Druckprotokoll einzuführen. Das Ergebnis waren lediglich weitere Inkompatibilitäten. Schließlich wurde eine Initiative zur Ausarbeitung eines neuen Industrie und IETF-Standards gegründet. Die Drucker-Arbeitsgruppe, ein loser Zusamenschluss von Hardware-, Software- und Betriebssystemherstellern entwarf das neue Internet Printing Protocol (&IPP;). &IPP; v1.1 wurde von der IETF (Internet Engineering Task Force) als Standard genehmigt und genießt nun die uneingeschränkte Unterstützung der Industrie in Europa, den USA und Japan. Die meisten momentan erhältlichen Netzwerkdrucker haben jetzt eine eingebaute &IPP; Unterstützung, die auf dem traditionellen LPR/LPD oder JetDirect aufsetzt. &IPP; verspricht die Lösung vieler Probleme, mit denen sich Netzwerkadministratoren konfrontiert sehen. Diese haben es normalerweise mit heterogenen Netzwerkumgebungen zu tun und verbringen mehr als die Hälfte ihrer Arbeitszeit mit Druckproblemen. Durch die Schaffung einheitlicher Abfragefunktionen für &IPP;-Drucker und -Server zur Übertragung von Dateien und zur Verwaltung von Druckaufträgen, ist &IPP; für den Einsatz über Betriebssystem-Plattformen hinweg geeignet. Die Umstellung auf &IPP; wird jedoch nicht über Nacht passieren, da viele alte Geräte noch über Jahre hinweg eingesetzt werden. Deshalb ist in &IPP; auch festgelegt, dass alle &IPP;-Implementierungen rückwärtskompatibel sind. ∪︀ beweist die Entwicklungsfähigkeit von &IPP; zum Drucken in allen Umgebungen. Der größte Vorteil wird die Integration in die vorhandenen, robusten IP-Protokolle sein. Als Erweiterung des bewährten und robusten HTTP 1.1 Protokolls an die speziellen Anforderungen von Druckdateien kann &IPP; sehr einfach andere Standards, die entwickelt werden, einbinden: Basic-, Digest-Authentifizierung und Authentifizierung über Zertifikate für Benutzer, die Zugang zu Druckdiensten benötigen. SSL3- und TLS-Verschlüsselung für den Datentransfer. Kommunikation in beide Richtungen zwischen Arbeitsstationen und Druckgeräten über den HTTP/&IPP; GET und POST Mechanismus. Die Integration von LDAP-Verzeichnisdiensten als einheitliche Datenbank zur Verwaltung der verfügbaren Drucker, deren Fähigkeiten und Seitenpreise &etc;. sowie von Benutzerpasswörtern, ACLs &etc;. PULL-Methode (im Gegensatz zur gewöhnlichen PUSH-Methode), bei der einem Server oder Drucker nur die &URL; eines Dokuments übergeben werden muss, und dieser dann selbstständig die Datei empfängt und ausdruckt. Haben Sie schon mal eine Vorführung der Netzwerkfähigkeiten von ∪︀ gesehen? Sie waren sicherlich ziemlich beeindruckt, wenn sie vorher nicht wussten, was sie erwartet. Stellen Sie sich vor, sie sind der Administrator eines LANs. Zu Testzwecken haben Sie eine &kde;/∪︀-Arbeitsstation installiert, die komplett mit einem Dutzend funktionierender Drucker ausgestattet ist: &PostScript;, LaserJets, InkJets und BubbleJets &etc;. Ihre &kde;-Benutzer sind sehr zufrieden, da sie die Fähigkeiten jedes Druckers voll ausschöpfen können. Sie haben zwei Stunden gebraucht, um alles perfekt zum laufen zu bekommen, und jetzt wollen alle hundert Benutzer des Netzwerks das Gleiche. Nochmal zwei Stunden Arbeit für jeden Rechner? Sie denken jetzt sicher: Das wird ein riesiger Aufwand. Falsch! Mit nur einer Einstellung auf Ihrer ersten ∪︀-Arbeitsstation machen Sie daraus einen Server. Installieren Sie danach ∪︀ auf fünf Rechnern als Arbeitsstation und wenn Sie zur ersten Arbeitsstation zurückkommen, werden Sie sehen, wie die Benutzer mit den Einstellungen der von Ihnen zu Anfang angelegten Drucker herumspielen. Wie durch Magie sind die Drucker auf allen fünf ∪︀-Arbeitsstationen im Druckdialog aufgetaucht. Ihre Benutzer können Drucken, ohne dass auf den Arbeitsstationen ein Treiber oder eine Druckerwarteschlange eingerichtet werden musste. Wie funktioniert das nun? Die Antwort ist überhaupt nicht kompliziert. Ist ein ∪︀-Server in einem LAN aktiv, sendet er die Namen der verfügbaren Drucker mit Hilfe des UDP-Protokolls und Port 631 an das LAN. Port 631 ist von der IANA (die Internet Assigning Numbers Authority) als Port dem Protokoll &IPP; zugewiesen worden. Alle ∪︀-Arbeitsstationen warten auf Port 631 auf Daten von sendenden ∪︀-Servern. Dadurch kennen alle Rechner die verfügbaren Drucker und erfahren gleichzeitig den Pfad zu diesen. Mit &IPP; das eine wirklich clevere Erweiterung von HTTP v1.1 ist, hat ∪︀ die Möglichkeit alle Objekte des Drucksystems über Universal Resource Locators oder URLs anzusprechen. Druckaufträge, die entfernt oder neu gestartet werden müssen, Drucker, die abgefragt oder eingestellt werden müssen, administrative Aufgaben, die auf dem Server erledigt werden müssen; das alles kann mit &IPP; und ∪︀ über bestimmte URLs erledigt werden. Viele wichtige Aufgaben können über die Web-Schnittstelle von ∪︀ erledigt werden, die &zb; mit &konqueror; bedient werden kann. Desweiteren können die Arbeitsstationen grundsätzlich jeden Drucker administrieren und benutzen, den sie sehen, so als wäre es ein lokal angeschlossener Drucker. Natürlich können Sie den Zugriff mit ACLs und anderen Maßnahmen beschränken, so dass nicht jede Arbeitsstation jeden Drucker nach Belieben benutzen kann. Die Arbeitsstationen können sogar ohne den richtigen lokal installierten Filter (oder Treiber) drucken. Wie funktioniert das nun? Möchte eine Arbeitsstation etwas über eineDruckeroption wissen oder diese Option auswählen, schickt die sie eine Anfrage (CUPS-get-ppd genannt) an den Server. Der Server teilt der Arbeitsstation alles über die Druckoption mit, die er aus der &PPD; ausgelesen hat. Der Benutzer der Arbeitsstation sieht dann die Optionen und kann die gewünschte auswählen. Er sendet dann die Druckdatei (normalerweise ungefiltertes &PostScript;) versehen mit den Druckoptionen an den Druckserver. &IPP; ist dabei das Übertragungsprotokoll. Die weitere Verarbeitung, insbesondere die Filterung zur Erstellung des Endformats für den Zieldrucker, findet dann auf dem Server statt, der über die dafür nötigen Programme (Treiber oder Filter) verfügt. Dadurch druckt die Arbeitsstation, ohne dass lokal ein Treiber installiert sein muss. Jede Änderung auf dem Servers, wie &zb; das Hinzufügen oder das Ändern von Druckern wird sofort, ohne weitere Einrichtung von der Arbeitsstationen übernommen. Eine andere weiterführende Funktionen in ∪︀ ist die Möglichkeit einen Lastenausgleich einzurichten. Richten Sie die gleiche Warteschlange auf zwei oder mehr Servern ein, senden die Arbeitsstationen ihre Aufträge an den ersten antwortenden oder verfügbaren Server. Das führt dann zu einem automatischen Lastenausgleich zwischen den Servern. Wenn Sie einen Server wegen Wartungsarbeiten vom Netz nehmen müssen,. übernehmen die anderen Server einfach dessen Arbeit, ohne dass die Benutzer der Arbeitsstationen einen Unterschied bemerken.