Teams, die Etiketten drucken, landen meist bei einem von
zwei Wegen: ein PDF erzeugen und es von einem Druckertreiber rastern
lassen, oder ZPL erzeugen und es unverändert an den Drucker schicken.
Beides funktioniert. Sie scheitern unterschiedlich — und genau diese
Fehlerbilder sollten die Wahl bestimmen.
Was in jedem Weg wirklich passiert
PDF-Weg: Ihre Anwendung baut eine Seite, ein Treiber
wandelt sie in Druckerpunkte, der Drucker brennt sie. Beim Erreichen der
Hardware ist das Etikett ein Bild.
ZPL-Weg: Ihre Anwendung gibt Textbefehle aus
(^FO, ^FD, ^BC), und Schriften wie
Barcodes zeichnet der Drucker selbst in seiner nativen Auflösung. Auf dem
Rechner rastert nichts.
Wo es jeweils weh tut
PDF-Weg
Natives ZPL
Barcode-Qualität
Hängt vom Rastern ab: ein skalierter oder
kantengeglätteter Barcode verliert die scharfen Balkenkanten, die Scanner
brauchen
Der Drucker erzeugt das Symbol in Geräteauflösung — der
übliche Grund, warum barcodelastige Arbeit zu ZPL wandert
Auftragsgröße und Tempo
Ein Vollseiten-Bitmap je Etikett;
größere Last, langsam über schmale Leitungen
Wenige hundert Byte
Text je Etikett
Schriften
Im PDF eingebettet, ungewöhnliche Schriften
reisen mit
Auf druckerresidente Schriften beschränkt, sofern Sie
keine Schrift hochladen
Layouttreue
Genau wie entworfen, solange der Treiber sich
benimmt
Genau wie geschrieben, aber Koordinaten sind Punkte und
hängen an der Auflösung
Infrastruktur
Treiber und meist ein Spooler auf einer
echten Maschine
Bytes an TCP-Port 9100; kein Treiber, von jedem
Server aus
Variable Daten in Masse
Ganze Seite je Datensatz neu
rendern
Nur die Datenfelder ändern
Ohne Reue wählen
Scannbare Barcodes, hohe Stückzahl, serverseitige
Erzeugung → natives ZPL. Dafür wurde die Sprache gebaut, und sie
nimmt den Treiber komplett aus der Gleichung.
Aufwendiges Grafikdesign, gelegentlicher Druck, vorhandene
PDF-Werkzeuge → PDF. Ein designtes Layout in ZPL nachzubauen ist
meist der falsche Tausch.
Beides ist legitim: das operative Etikett in ZPL, das
Archiv- oder Kundendokument als PDF. ZPL nach PDF zu rendern ist zudem der
Weg zu einem druckbaren Andruck ohne Drucker — ein Auftrag, zwei
Ausgaben.
Ein Hinweis vor der Festlegung
Kein Weg erspart Ihnen die Auflösungsfrage. Ein in Punkten für 203 dpi
geschriebenes ZPL-Layout druckt auf einem 300-dpi-Kopf etwa auf zwei
Dritteln, und ein in falscher physischer Größe gestaltetes PDF ist auf
Papier genauso falsch. Deklarieren Sie die echte Etikettengröße und prüfen
Sie sie vor dem ersten Produktionslauf.
Beide Ausgaben derselben Datei sehen Sie hier: ZPL in den
ZPL-Viewer einfügen oder über die
API PNG bzw. PDF aus derselben Quelle holen.
Weicht das Druckergebnis ab, grenzt die
Fehlersuche-Triage es ein.
Häufig gestellte Fragen
Ist ZPL besser als PDF für den Etikettendruck?
Für scannbare Barcodes in Masse meist ja: Der Drucker erzeugt das Symbol in eigener Auflösung, Aufträge sind wenige hundert Byte groß, und kein Treiber ist beteiligt. PDF passt besser zu aufwendigen Layouts, gelegentlichem Druck oder wenn vorhandene PDF-Werkzeuge das Dokument ohnehin erzeugen.
Warum scannen Barcodes aus PDF schlechter?
Weil die Seite vor dem Drucker gerastert wird. Skalierung und Kantenglättung verwischen die Balkenkanten, auf die Scanner angewiesen sind. Natives ZPL vermeidet das, indem der Drucker das Symbol in Geräteauflösung zeichnet.
