(12. März 2005 — tk)

Welches Druckerprotokoll in welcher Situation?

Nachfolgend ein paar grundsätzliche Überlegungen bzgl. verschiedener Druckerprotokolle. Wir unterscheiden dabei verschiedenene Szenarien — mal mit und mal ohne »großen« Printserver. Vorab aber zu Zielen und den Begrifflichkeiten…

Ziele und Auswahlkriterien

Anforderungen an Netzwerk-Druckerprotokolle sind in jedem Fall:

  • Geschwindigkeit: Hierbei ist unbedingt darauf zu achten, »real world«-Bedingungen im Hinterkopf zu haben und nicht das Ganze auf einen synthetischen Benachmarktest bzgl. der reinen Transfergeschwindigkeit zu reduzieren. Wichtig ist auf der einen die Zeit, die der Druckjob vom Abschicken bis zur Ausgabe der Seite braucht und auf der anderen, wie hoch der Gesamtdurchsatz bei vielen Jobs ist.
  • Produktionssicherheit — Die Frage hier lautet: Wie problemlos lassen sich alle Arten von Jobs durch das Netzwerk schleusen ohne daß es zu unerklärlichen Abbrüchen oder RIP-Fehlern kommt.
  • Komfort: D.h. wie simpel ist es für den Benutzer möglich, in einem Netzwerk die verfügbaren Drucker zu finden und andererseits die richtigen druckerspezifischen Einstellungen (PPD) auszuwählen? Und wie einfach wird es ihm gemacht, Fehlerzustände des Druckers (Papier aus, Job bricht wegen Fehler ab, etc.) mitzubekommen ohne daß er den Drucker selbst visuell überwachen muß)?

Druckserver-Arten:

Wir unterscheiden im Folgenden sehr klar zwischen »kleinen« Druckservern, die lediglich eine Durchreiche-Funktion für lokal angeschlossene Geräte bereitstellen und »großen« Printservern, die auf einem dedizierten Server laufen und dort noch weitere Aufgaben wie bspw. eine Filterung (Formatkonvertierung) übernehmen können oder mit zentralen Queueing-Mechanismen die Administration vieler Drucker bequem ermöglichen.

Auf dem Weg von der Anwendung zum Drucker kann ein Druckjob durchaus mehrere verschiedene und nicht unbedingt gleichartige Druckserver passieren.

  • Die primitivste Gruppe stellen die in Druckern direkt eingebauten Printserver dar wie auch externe Kistchen, die beide nicht mehr machen, als einen per USB, seriell oder Parallelport angeschlossenen Drucker mehr oder weniger direkt ins Netzwerk zu stellen (sei es per Ethernet-Kabel oder drahtlos per WLAN). Meist fehlen hier auch primitivste Mechanismen, um Druckdaten für die Anschlußmethode passend (per BCP oder TBCP) zu kodieren — siehe unten. Allerdings können die besseren internen Varianten (bspw. die HP JetDirects für den »MIO-Slot«) wenigstens Drucker-Statusmeldungen an den sendenden Rechner schicken, wenn über ein bidirektionales Protokoll gedruckt wird.
  • »Ausgewachsene« Host-basierende Druckserver bieten deutlich mehr Möglichkeiten. Neben ausgefeilten Queueing-Fähigkeiten, bei denen der Druckserver gegenüber Clients als »Spooler« agiert, d.h. Druckjobs durch Zwischenspeichern auf Platte auch entgegennehmen kann, selbst wenn der Drucker aktuell mit einem anderen Job belegt ist, stehen hier meistens auch noch weitreichende Möglichkeiten der Druckdatenmanipulation zur Verfügung:
    • Neu-Kodierung der Druckdaten, um das Ausgabegerät passend beschicken zu können.
    • Format-Konvertierung, d.h. Umwandlung von bspw. reinem Text oder Bildformaten wie JPEG in die Druckersprache, also bspw. PostScript, PCL, ESC/P, etc.
    • Ist der Druckserver noch weiter aufgebohrt — bspw. ein OPI-Server — so können in PostScript- (oder neuerdings auch PDF-) Dateien auch noch fehlende Schriften eingebettet werden, niedrig aufgelöste Platzierungsbilder durch hochaufgelöste ersetzt werden, Farbraumkonvertierungen für enthaltene Bilddaten durchgeführt werden, etc.
      Diese Printserver-Gruppe kann auch als Gateway zwischen verschiedenen Druckerprotokollen eingesetzt werden, also bspw. einen reinen AppleTalk-fähigen Drucker allen Windows- und Unix-Clients im Netz verfügbar machen oder umgekehrt.

Weiterhin spannend bei der Betrachtung von Druckservern ist ihr Maß an Bidirektionalität, also ob sie Informationen, die sie auf der Ausgabeseite entgegennehmen, auch auf der Eingabeseite bereitstellen können. Vorteile einer solchen Bidirektionalität sind Kommunikation von Konfigurations- und Status-Informationen vom Drucker wenn möglich bis zurück in die druckende Anwendung bzw. eben bis zum Anwender.

(Neu-)Kodierung des Druckdatenstroms:

Speziell im Zusammenhang mit PostScript ist in vielen Situationen die »Kodierung« des Druckdatenstroms von Interesse. Das ursprünglich von Adobe spezifizierte »Standardprotokoll« war auf die Ansteuerung von seriell oder parallel angeschlossenen Druckern ausgerichtet, bei denen ASCII-Zeichen <32 oder >127 teils eine spezielle Bedeutung hatten. Problematisch wurde das, wenn in Druckjobs eben jene Zeichen bzw. Byte-Werte vorkommen. Ein Ausweg aus dem Dilemma sind spezielle Kodierungsvarianten, die trotzdem ermöglichen, daß ursprünglich »binär« kodierte Seitenelemente heil auf dem Drucker ankommen:

  • ASCIIhex: Bei dieser Variante werden Binärdaten ziemlich primitiv kodiert, indem einfach die Datenmenge verdoppelt wird (in der Datei finden sich die Bytes als hexadezimale Werte wieder). Dieses Kodierungsschema funktioniert auch mit den allerersten PostScript Level 1 Interpretern problemlos.
  • ASCII85: Eine weitere ASCII-Kodierungsvariante, die aber deutlich sparsamer mit dem Speicherplatz umgeht — dafür aber auch erst mit PostScript-Interpreter ab Version 2 funktioniert: Es werden aus 4 Bytes im Original deren 5 in der ASCII85-kodierten Variante gemacht (ausnützend, daß eine 4-stellige Zahl mit der Basis 256 problemlos in eine 5-stellige mit der Basis 85 paßt. Damit kann man 4 »vollwertige« 8-Bit-Zeichen mit 5 Bytes abbilden, die sich allesamt im »unschädlichen« Bereich von 32-127 tummeln.
  • (Tagged) Binary Control Protocol — BCP/TBCP: Hier werden evtl. störende Steuerzeichen per »Quoting«, also dem Voranstellen eines speziellen Zeichens, geschützt und dadurch unschädlich gemacht. So kann auch bspw. das früher so gefürchtete »Ctrl-D« (ASCII-Wert 13), das bei Ausgabe auf dem Parallelport das Signal für das Druckjobende ist, in Bilddaten vorkommen, weil es im Ausgabestrom entsprechend geschützt wird.
  • Binary: Dies stellt genaugenommen gar keine spezielle Kodierungsvariante dar sondern einfach nur das ungefilterte Durchreichen auch binärer Job-Elemente bis zum Drucker. Gemäß Adobes »Document Structuring Conventions« (DSC) müssen binäre Bereiche innerhalb PostScript-Dateien aber durch DSC-Kommentare gekennzeichnet sein, damit Druckserver gegebenenfalls diese Blöcke passend neu kodieren können, wenn bekannt ist, daß der Drucker oder »weiter hinten« im Workflow stehende Druckserver Probleme mit binären Daten bekommen sollten.

Wechselwirkungen — Probleme

[to be continued]

PAP (AppleTalk) bspw. ist bedingt durch das ineffiziente DDP-Transportprotokoll ziemlich langsam, wenn man die reine Transfergeschwindigkeit über das Netz betrachtet. Da bei PAP im Idealfall aber die Druckdaten sofort als konstanter — wenngleich langsamer — Datenstrom zum Drucker wandern und nicht wie bei anderen Lösungen mindestens einmal lokal gespoolt werden müssen, kann es sein, daß die

Copyright © Thomas Kaiser, 2008 (erstellt 12. März 2005 — tk)

Dieser Beitrag kann durch jedermann gemäß den Bestimmungen der Lizenz für die freie Nutzung unveränderter Inhalte genutzt werden. Die Lizenzbedingungen können unter http://www.uvm.nrw.de/opencontent abgerufen oder bei der Geschäftsstelle des Kompetenznetzwerkes Universitätsverbund MultiMedia NRW, Universitätsstraße 11, D-58097 Hagen, schriftlich angefordert werden.