PDF zu nativem ZPL
Ein PDF- oder SVG-Etikett hochladen: Text wird zu ^A0-Feldern, Barcodes werden dekodiert und als native ^B-Befehle neu erzeugt (und geprüft), Linien, Rahmen und Kreise werden zu ^GB/^GC/^GE - nur was kein natives Gegenstück hat, bleibt eine ^GF-Grafik. Das Ergebnis wird Pixel für Pixel mit dem Original verglichen.
Dieses Tool per API automatisieren: POST /v1/tools/pdf-to-native-zpl
API-Doku
Warum natives ZPL statt eines Bildes
Die meisten PDF-zu-ZPL-Konverter machen aus der ganzen Seite ein ^GF-Bitmap: Das druckt, ist aber groß, nicht bearbeitbar, und die Barcodes sind nur so scharf wie das Raster. Vector-Lift liest stattdessen die Objekte des PDFs - Text, Pfade, Bilder - und schreibt sie als das, was ein Zebra-Drucker selbst versteht. Barcodes werden dekodiert, mit dem passenden ^B-Befehl neu erzeugt und erneut dekodiert; die Daten müssen identisch sein. Für Fotos, aufwendige Grafik und mehrseitige Stapel bleibt der Raster-Konverter die richtige Wahl.
Nativ: Text (^A0, auf Breite und Grundlinie eingepasst; weiß auf schwarz als ^FR), Code 128/GS1-128, EAN/UPC, Code 39/93, Interleaved 2 of 5, Codabar, QR Code, Data Matrix, PDF417, Aztec, MaxiCode, Linien, Rahmen, abgerundete Rahmen, Kreise, Ellipsen und Diagonalen. Bleibt Grafik: Logos, Fotos, Verläufe, gestapelte Codes, GS1 DataBar und Text, der als Kontur ohne Textebene gezeichnet ist (keine Texterkennung). Jedes Ergebnis zeigt die Treue, den nativen Anteil und die Größe im Vergleich zu einem reinen ^GF-Raster. Dateien werden in einem isolierten Prozess verarbeitet und nicht gespeichert.
Passend dazu: PDF zu ZPL wandelt jede Seite in ein ^GF-Bild um (exaktes Aussehen, jeder Inhalt), ZPL-Diff vergleicht zwei Etiketten Pixel für Pixel. Engine: zplCore.com Vector-Lift.