Ein Druckertreiber hat genau eine Aufgabe: Dokumente — Word-Seiten,
Browser-Ausdrucke, PDFs — in die Sprache eines bestimmten Druckers zu
übersetzen. Eine ZPL-Datei überspringt diesen Schritt per Definition:
Sie ist bereits die Sprache des Druckers, und dessen eigene
Firmware übernimmt das Rendern. In einem ZPL-Workflow fügt ein Treiber
nichts hinzu — er kann sogar schaden: Eine Queue mit Treiber hält den
ZPL-Quelltext für ein Dokument und druckt die Befehle als sichtbaren
Text.
Weg 1 — direkt zum Socket
Die meisten Netzwerk-Thermodrucker nehmen rohe Befehle auf TCP-Port
9100 an. Alles, was einen Socket öffnen kann, kann drucken — kein
Drucksystem, keine Installation. Die Befehle für jedes Betriebssystem
und die "es druckt nichts"-Checkliste stehen in
ZPL an einen
Netzwerkdrucker senden.
Weg 2 — eine Raw-Queue in CUPS (macOS/Linux)
Teilen sich mehrere Personen oder Systeme einen Drucker, bringt eine
Warteschlange Spooling, Reihenfolge und Wiederholungen. Unter macOS und
Linux heißt das: CUPS mit einer Raw-Queue — eine
lpadmin-Zeile; Einrichtung und macOS-Besonderheiten stehen
in ZPL unter macOS und
Linux drucken.
Weg 3 — Windows ohne Zebra-Treiber
Auch Windows kann Bytes durchreichen. Das bekannte Rezept: einen
Drucker auf einem Standard-TCP/IP-Port anlegen (Protokoll RAW,
Port 9100) und den eingebauten Treiber Generic / Text Only
wählen — er versucht nicht, ZPL in Grafik zu rendern, der Befehlsstrom
erreicht den Drucker. Ist der Drucker freigegeben, funktioniert der
klassische Einzeiler weiterhin:
copy /b etikett.zpl \\PC-NAME\zebra
Aus Code nimmt der Win32-Spooler Aufträge mit dem Datentyp RAW an
(z. B. Pythons win32print) — dasselbe
Durchreich-Versprechen, ausdrücklich gemacht.
Wann will man also einen echten Treiber?
Wenn das zu Druckende ein Dokument ist, kein ZPL: in Word
gestaltete Etiketten, ein Lieferschein aus dem Browser, ein PDF. Dann
muss etwas Seiten in Druckerbefehle übersetzen — genau die Aufgabe des
Treibers. Beide Workflows leben als zwei Queues für ein Gerät friedlich
nebeneinander: eine Raw-Queue für ZPL, eine mit Treiber für Dokumente.
Probleme beginnen erst, wenn ein Auftrag die falsche Tür nimmt.
Die zwei klassischen Symptome
1. Der Drucker hat meinen ZPL-Code als Text gedruckt. Der
Auftrag lief durch einen Treiber oder Filter, der ihn als Dokument
behandelte. Auf den rohen Weg umziehen — das ZPL selbst ist in
Ordnung.
2. Es passiert gar nichts. Rohe Wege sind absichtlich stumm;
die Checkliste im
Netzwerkdruck-
Leitfaden der Reihe nach abarbeiten — und weil rohe Wege auch kein
Zurück kennen: das Etikett vorher im
Online-Viewer prüfen, bevor es
Material kostet.
Häufig gestellte Fragen
Warum hat mein Drucker die ZPL-Befehle als Text gedruckt?
Der Auftrag lief durch einen Treiber oder Filter, der den ZPL-Quelltext als zu renderndes Dokument behandelte. Den Auftrag auf einen rohen Weg umziehen — Socket, CUPS-Raw-Queue oder Windows Generic/Text Only — das ZPL selbst ist in Ordnung.
Kann Windows rohes ZPL ohne Zebra-Treiber senden?
Ja: den Drucker auf einem Standard-TCP/IP-Port anlegen (Protokoll RAW, Port 9100) mit dem eingebauten Treiber Generic / Text Only, copy /b an einen freigegebenen Drucker verwenden oder aus Code Spooler-Aufträge mit Datentyp RAW übergeben.
Wann brauche ich den echten Treiber des Druckers?
Beim Drucken von Dokumenten — Word-Seiten, Browser-Ausdrucke oder PDFs — muss etwas die Seiten in Druckerbefehle übersetzen, und genau das ist die Aufgabe des Treibers. Eine Raw-Queue für ZPL und eine Queue mit Treiber für Dokumente können dasselbe Gerät nebeneinander bedienen.
