Eine ZPL-Datei enthält kein Bild Ihres Etiketts, sondern die
Anweisungen zum Zeichnen. Solange nichts diese Anweisungen ausführt,
gibt es nichts zu sehen — deshalb besteht der klassische Weg der Kontrolle im
Drucken, ein Testetikett pro Versuch.
Möglichkeit 1: ein Online-ZPL-Viewer
Der schnellste Weg ist ein Renderer im Browser.
Der Online-ZPL-Viewer von Labelixa zeichnet das
Etikett in echter physischer Größe: Code einfügen (oder Datei öffnen),
Etikettengröße und Druckdichte wählen — das Ergebnis erscheint sofort.
Strukturelle Fehler — ein fehlendes ^FS, ein Feld außerhalb des
Etiketts — werden mit Zeilennummer aufgelistet; ein physischer Drucker sagt
Ihnen das nie.
Möglichkeit 2: Rendern über eine API
Wenn Sie Vorschauen im eigenen Ablauf brauchen — eine Webanwendung, die das
Etikett vor dem Druck anzeigt, oder ein CI-Check für Etikettenvorlagen —
liefert eine Render-API das Etikett als PNG oder PDF aus einer einzigen
HTTP-Anfrage. Ein curl-Aufruf genügt, um einen ZPL-String in ein
Bild zu verwandeln; die genaue Anfrage steht in der
API-Referenz.
Möglichkeit 3: in eine Datei drucken
Manche Zebra-Drucker und -Treiber lassen sich so konfigurieren, dass die
Ausgabe in eine Datei statt auf Papier geht; Zebras eigene Einrichtungstools
bieten für bestimmte Modelle auch Vorschaufunktionen. Das funktioniert, setzt
aber voraus, dass der Drucker (oder sein Treiber) bereits eingerichtet ist —
genau die Abhängigkeit, die man in der Entwurfsphase meist vermeiden will.
Teams, die Etiketten im Code erzeugen, fragen oft, wie sie diese testen
sollen, wenn am Build-Rechner kein Drucker hängt. Für den Teil, der am
häufigsten bricht — das Etikett selbst — braucht es keinen Drucker. Zwei
Befehle genügen:
Der erste lässt den Build scheitern, wenn eine Vorlage einen Fehler oder
eine Warnung hat (unbekannter Befehl, Feld außerhalb des Etiketts, fehlendes
^XZ); der zweite schreibt ein PNG jedes Etiketts, sodass jemand
das Ergebnis in den Build-Artefakten prüfen kann. Was CI nicht prüfen kann,
ist die physische Seite — Material, Schwärzung, Kalibrierung, der Netzwerkweg
zum Drucker —, deshalb vor einem Release einen echten Testdruck behalten.
Fertige Pipelines für GitHub Actions, GitLab, Azure und Bitbucket stehen in der
CLI-Dokumentation.
Worauf in der Vorschau zu achten ist
Zuerst die Dichte. Die dpmm der Vorschau muss zu Ihrem
Drucker passen (8 dpmm = 203 dpi ist am verbreitetsten). Ein mit
falscher Dichte geprüftes Etikett sieht am Bildschirm richtig und auf Papier
falsch aus.
Echte Größe. Vergleichen Sie die Vorschau mit den
physischen Etikettenmaßen — Inhalt jenseits von ^PW/^LL
wird beim Druck stillschweigend abgeschnitten.
Barcode-Lesbarkeit. Prüfen Sie, ob Barcodes mit sinnvoller
Modulbreite gezeichnet werden; ein zusammengestauchter Barcode wird nicht
gelesen.
Häufig gestellte Fragen
Kann ich ZPL ohne Installation ansehen?
Ja. In einen Online-ZPL-Viewer einfügen — das Rendering läuft serverseitig, der Browser zeigt nur das Bild an.
Entspricht die Vorschau exakt dem gedruckten Etikett?
Layout und Inhalt stimmen bei der gewählten Punktdichte überein. Physische Faktoren — Schwärzung, Material, Kopfverschleiß — zeigt nur ein echter Druck; vor der Produktion bleibt ein letzter Prüfdruck.
Wie erzeuge ich Vorschauen automatisch aus Code?
Eine Rendering-API aufrufen: das ZPL per HTTP-Request senden und PNG oder PDF zurückbekommen. Damit wird die Vorschau ein Schritt, der in Tests und CI laufen kann.
