(09. Juli 2004 — tk)

Unterschiede der verschiedenen Druckerprotokolle

Für die Ansteuerung von Druckern gibt es verschiedene Protokolle. Diese unterscheiden sich in vielerlei Hinsicht bezüglich der unterstützten Features, Geschwindigkeit, etc. Wir versuchen im Folgenden mal einen Eindruck von den Druckvorstufen-relevanten Protokollen zu bekommen.

PAP — Printer Access Protocol (AppleTalk)

Dieses ein wenig in die Jahre gekommene Protokoll besitzt zwei herausragende Eigenschaften: Auf der einen Seite Bidirektionalität, d.h. Austausch zwischen Drucker (Spooler) und Spooler (Mac) über Ausstattungsmerkmale des Druckers (Feature Queries) und Fehlerzustände (Status Queries) und andererseits die Möglichkeit, uneingeschränkt auch binäre Bilddaten zu transportieren (8 Bit Fähigkeit). Nachteil: die geringere Effizienz bei Ethernet (Ein Ethernet Frame ist zu 2/3 leer, wenn er ein 576 Bytes langes AppleTalk Paket transportiert)

Weitergehende Informationen: http://developer.apple.com/documentation/mac/NetworkingOT/NetworkingWOT-75.html

Remote LPR

Per Definition genau das Gegenteil im Vergleich zu AppleTalk, d.h. nicht »8 bit save« (per Definition muß damit gerechnet werden, daß das 8. Bit von irgendeinem LPR-fähigen Task auf dem Weg von der Anwendung zum Drucker gekappt wird. LPR ist nur für plain-ASCII, also 7 Bit, spezifiziert. Des weiteren ist remote LPR Einbahnstraße, d.h. es kann weder Features noch Statusmeldungen kommunizieren. Und schließlich besteht noch ein Problem darin, daß Druckjobs vor dem Versand deren Größe mitgegeben werden muß. Das bedeutet in Konsequenz, daß der Druckjob auf dem Server immer erst lokal gespoolt werden muß (um die Größe zu ermitteln), bevor er per remote LPR transferiert werden kann. In der Praxis ist das aber heute keine allzu große Einschränkung mehr, speziell wenn man die relativ kleinen Druckjobs für Laserdrucker und die Performance heutiger Server berücksichtigt.

Weitergehende Informationen unter http://www.uni-kiel.de/rz/ausgabe/drucken_unix/drucken_unix.html und http://www.faqs.org/rfcs/rfc1179.html und http://www.faqs.org/rfcs/rfc1179.html

TCP/IP Streams bzw. »socket«

TCP/IP Streams ist von der eigentlichen Übertragungsseite eigentlich das primitivste der Protokolle. Man öffne eine Socket-Verbindung, schiebe Daten durch die Gegend und schließe die Verbindung (bzw. lasse ein Timeout wirken, wenn einer der beiden Partner abstürzen sollte). TCP/IP Streams ist grundsätzlich binary-fähig, wenngleich das in der Praxis sehr stark von der Implementation abhängt. Dito mit der Rückkanalfähigkeit. Einige Hersteller professioneller RIPs implementieren das in der Art, daß einem anfragenden Client auf ${port} + 1 geantwortet wird, bei normalen Desktop-Druckern wird meistens versucht, auf dem selben Port zu antworten, wenn der Drucker denn überhaupt Bidirektionalität anbietet.

Wenn ein Device mehrere Drucker/Spooler per TCP/IP Streams anbietet, dann findet eine Differenzierung nur über unterschiedliche Portnummern statt, was es für den Endanwender schwierig macht, den gewünschten Service zu benutzen.

Weiterführende Informationen: http://www.lprng.com/LPRng-Reference-Multipart/socketapi.htm

Internet Printing Protocol (IPP)

Dieses recht junge, auf HTTP aufsetzende Protokoll verspricht viele Probleme der Vergangenheit zu lösen. Es läßt sich quer durchs Internet über Firewalls transportieren, beherrscht Authentifizierung und Host-basierenden Zugriffsschutz, kommt mit eingebauten Fähigkeiten zur Service-Lokalisierung (wenigstens wenn CUPS im Spiel ist) und wird inzwischen von nahezu allen aktuellen Betriebsystemen von Haus aus unterstützt.

Allerdings steht IPP/CUPS im Ruf, bisweilen recht komplex zu sein und für viele Anwender sind die flexiblen Möglichkeiten, die CUPS bietet, zuviel des Guten (speziell unter MacOS X, wo Apple nur zum Teil CUPS nutzt und noch ein paar Modifikationen eingebracht respektive Subsysteme angebaut hat). Scheinbar willkürliche Änderungen des Dokumenttyps oder »im Nirvana verschwindende« Druckjobs sind Symptome für die zugrunde liegenden Probleme.

Weitergehende Informationen unter http://www.pwg.org/ipp/index.html zu finden.

HELIOS TCP/SLP

Im eigentlichen Sinn handelt es sich hierbei nicht um ein neues Protokoll, sondern um eine proprietäre Verschmelzung verschiedener Technologien, um Mac-Clients das Drucken auf EtherShare-Server zu erlauben. Gedruckt an sich wird »8 bit save« per TCP/IP Streams wobei per Definition immer auch ein Rückkanal für Statusmeldungen des Servers zur Verfügung steht. »Service Location« findet per SLP statt, d.h. im Gegensatz zu klassischen TCP/IP Streams Services können damit auch problemlos ‘zig Spooler je Server gefunden und angesteuert werden. Raffiniert ist ebenfalls, daß bei dieser Variante beim Einrichten des Druckers automatisch auch die PPD vom Server auf den MacOS X Client transferiert wird, d.h. der Nutzer auch automatisch mit den richtigen Einstellungen druckt.

Weitergehende Informationen: http://www.helios.de/support/manuals/TCP-e/tcp-html/Output/TCP-IP_Printing.html

Nicht alle Protokolle sind für alle »Produktionsstrecken« gleich gut geeignet. Hier findet sich eine nähere Betrachtung, welches Druckprotokoll wann zu bevorzugen ist.

Copyright © Thomas Kaiser, 2008 (erstellt 09. Juli 2004 — 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.