zplCore.com · High Performance .NET Labelprint Engine
.NET 10 · ZPL II · EPL2 · Barcodes
zplCore.com ist das ZPL-SDK für .NET und C#: Etiketten aus Vorlagen und Daten als ZPL erstellen, ZPL II und EPL2 wie ein virtueller Zebra-Drucker als PNG oder PDF prüfen und an den Drucker senden. 144 Barcode-Symbologien sind eingebaut. Läuft unter Windows, Linux und macOS, ohne Druckertreiber.
Die Label-Cloud-Plattform auf Basis von zplCore →
Alle Tools auf zplCloud.com → ZPL → PDF/PNG, PDF/Bild → ZPL, Linter, Barcode-Prüfung
gerendert mit zplCore.com · PNG
Auf einen Blick
Funktionen
Vorlage + Daten (C#-Objekte, JSON, EF Core) → ZPL
144 Symbologien, von Code 128 über GS1 DataBar und QR bis MaxiCode, DotCode und Han Xin. Ausgabe als PNG, SVG, PDF, EPS oder ^GFA. GS1-Validierung inklusive.
Text, Barcode, Tabelle, Bild, RFID in mm oder Zoll. Ausdrücke mit Element-Referenzen, Validierung, AutoFit, Duplex mit Vorder- und Rückseite. Mehrsprachige Vorlagen mit {t:key} und Kultur pro Druckauftrag. Speichern und Laden als JSON-Vorlage.
label.For<T>() bindet C#-Objekte, EF-Core-Abfragen und MongoDB- oder LiteDB-Dokumente per LINQ. Dazu JSON (JsonElement) und dynamische Datensätze. Streaming mit konstantem Speicher, asynchron in Stream und PipeWriter.
Verkleinert ZPL ohne Pixeländerung: entfernt redundante Befehle und Standardparameter und komprimiert Grafiken neu (Hex, ACS, Z64). Pixelgleich geprüft am gesamten Referenzkorpus.
ZplRescaler rechnet Roh-ZPL zwischen 203, 300 und 600 dpi um. ZplGraphicEncoder kodiert Bilder als Hex, ACS, Z64 oder B64 mit 5 Dithering-Verfahren.
ZPL/EPL → PNG, PDF, SVG wie ein virtueller Zebra-Drucker
Ausgabe als PNG, JPEG, WebP, BMP, GIF, PDF, GRF, HTML, EPS, TIFF (CCITT G3/G4, LZW, Deflate, PackBits, mehrseitig), PCL (mono, grau, farbig) und ESC/POS mit NV-Logos. Gespeicherte Formate mit ^DF/^XF, Grafiken, Barcodes, Fonts.
Ganze Labels als SVG und PDF in Vektorform: Text als Glyphen-Umrisse, Barcodes und Rahmen als Pfade, Grafiken als 1-Bit-Bilder. Jedes SVG-Element trägt seine Position im ZPL-Quelltext. Rückgerastert stimmt die Ausgabe mit dem PNG überein (Mittelwert 1,000 bei 2 Dots Toleranz, 126 Labels).
EPL2 läuft durch dieselbe Engine. ToZpl() konvertiert bestehende EPL-Formulare nach ZPL.
Strukturierte Diagnosen mit stabilen Codes. Jedes gerenderte Element kennt seine Position im ZPL-Quelltext und lässt sich als JSON ausgeben. Schutzgrenzen für fremdes ZPL.
Automatisierter Pixelvergleich gegen druckergenaue Referenzrenderings, im Mittel 0,986 über 169 Testfälle. QR-Codes (^BQ, Modell 2) sind modulgleich mit dem Zebra-Druckbild – Moduswahl, Version, Fehlerkorrektur und Maske, geprüft an über 3.600 Labelary-Referenzsymbolen. QR-Modell 1 wird als Modell 2 ausgegeben. Barcode-Encoder sind bit-genau gegen bwip-js geprüft.
HarfBuzz-Shaping und Bidi für Arabisch, Hebräisch, Thai, indische Schriften und CJK.
TCP 9100, USB, Windows-Spooler, CUPS, virtueller Drucker
Start-Label, Datensätze, End-Label und Schnitt nach dem letzten Etikett in einem Job. Transport über TCP 9100, seriell, USB, Windows-Spooler oder CUPS. ^MM/^MN/^MT, erweiterter ~HQ-Status, Probelauf.
ZplVirtualPrinter lauscht auf TCP 9100, rendert eingehende Druckjobs und antwortet auf Statusabfragen. Testen ohne Hardware, auf Wunsch mit simulierten Druckerfehlern und Cutter.
Das dotnet-Tool zplcore rendert, konvertiert EPL nach ZPL, druckt, erzeugt Barcodes, formatiert und vergleicht ZPL, prüft Etiketten (comply, verify, check) und schwärzt personenbezogene Daten.
TTF-Schriften gehen über ~DY in den Druckerspeicher oder werden als Grafik gedruckt (PrintAsGraphic).
Prüfen & Simulieren
Rendern ist erst der Anfang. zplCore.com prüft Etiketten gegen GS1- und Carrier-Regeln, liest jeden Barcode zurück, simuliert Drucker samt Fehlern und macht Etiketten testbar wie Code. Alles offline, im eigenen Prozess und in der CI.
84 Regeln in 8 Paketen: GS1-Logistiketikett, Sunrise 2027, Amazon FBA, UPS, FedEx, DHL Paket, UDI und RFID. Gemessen am gerenderten Etikett (X-Dimension, Ruhezonen, Klarschrift, AI-Formate, Prüfziffern), jeder Fund mit Zeile, Position und Quelle, als JSON, SARIF oder markiertes PNG. Eine Vorprüfung, keine Zertifizierung.
Jeder Barcode wird aus dem gerenderten Bild mit zwei unabhängigen Decodern zurückgelesen und mit den Solldaten verglichen. X-Dimension, Ruhezonen, Höhe und Überlappungen werden vermessen, dazu eine Note A–F als digitaler Vorab-Check nach dem Vorbild von ISO/IEC 15415/15416. Ein Prüfgerät am gedruckten Etikett ersetzt das nicht.
Bestehendes ZPL wird zur datengebundenen Vorlage: Text, Barcodes, Formen, Bilder und RFID als typisierte Elemente, ^FN-Felder als Datenfelder. Jedes Element wird pixelweise gegengeprüft; alle 318 Dateien des Testkorpus kommen pixelgleich zurück.
Liest Empfänger, Absender, Sendungsnummern mit Prüfziffer, SSCC, GTIN, Daten und Gewichte aus dem ZPL, mit Fundstelle und Konfidenz. Die Schwärzung ersetzt personenbezogene Daten im gleichen Layout, auch in Kommentaren und 2D-Codes, und sucht danach erneut. Regelbasiert, ohne Netzwerk; vor der Weitergabe bitte prüfen.
Findet die GTIN in EAN/UPC, GS1-128, ITF-14 oder DataBar und ergänzt im freien Platz einen QR-Code mit GS1-Digital-Link-URI oder einen GS1 DataMatrix, mit Ruhezone und Sunrise-Vorprüfung. Digital-Link-URIs bauen und parsen nach URI Syntax 1.7.0.
EPCs kodieren und dekodieren nach GS1 EPC Tag Data Standard 2.3 (SGTIN, SSCC, SGLN, GRAI, GIAI und die TDS-2.0-Plus-Schemata) samt passender ^RF-Befehle. Prüft, ob der Tag dieselbe SSCC oder GTIN trägt wie das gedruckte Etikett.
Druckt dieses Etikett auf diesem Modell? 24 Geräteprofile (u. a. ZD421, ZD621, ZT411, ZT610, ZQ630*) melden Felder außerhalb der Druckkopfbreite, fehlende Optionen wie Cutter oder RFID, Firmware-Grenzen, Fonts und Speicher, dazu eine Druckzeitschätzung. Jede Profilangabe ist mit Quelle belegt oder als unbekannt markiert.
Der virtuelle Drucker auf TCP 9100 fällt auf Wunsch aus: Papier oder Farbband leer, Kopf offen, Verbindungsabbruch, Timeout, per Skript und reproduzierbar. ~HS und ~HQES antworten wie ein Drucker. Die Cutter-Simulation zeigt, nach welchen Etiketten geschnitten wird, mit Schnittlinien in PNG, SVG und PDF.
Etiketten testen wie Code: ZplAssert.Label(zpl) prüft, ob der SSCC-Barcode die erwarteten Daten liefert, dazu Überlappung, Clipping, Compliance, Druckerprofil, Pixel- und Semantik-Snapshots. Fehler nennen Element, Position und ZPL-Zeile. zplcore check und eine GitHub Action kommentieren Pull Requests mit Vorher/Nachher-Bildern.
zplcore-mcp gibt Claude Code, Claude Desktop, VS Code und Cursor 26 Werkzeuge: rendern, linten, Compliance, Scan-Proof, Schwärzen, Printer Twin und mehr. Nur stdio, kein Netzwerk-Port; jeder Aufruf läuft in einem eigenen Worker-Prozess mit Zeit- und Speicherlimit, ohne Zugriff auf Dateien und Netz.
Vector-Lift macht aus Carrier- und ERP-PDFs oder SVGs echtes ZPL statt eines ^GF-Rasterbilds: Text als ^A0-Felder, Barcodes neu erzeugt und gegengelesen, Linien und Rahmen als ^GB/^GC/^GE. Mit gemessener Übereinstimmung je Etikett und Element.
SDK, Testing-Paket, CLI und MCP-Server bauen ohne Trim- und AOT-Warnungen. Als NativeAOT-Container auf runtime-deps:10.0-noble-chiseled-extra (~79–105 MB) startet alles ohne .NET-Laufzeit – geprüft auf macOS, Linux (arm64/x64) und als lokaler Labelprint-Server auf einer Synology DS923+ (793/793 Ausgaben identisch zur JIT-Version, 24 % schneller).
Echte Ausgaben der Engine, erzeugt aus den Beispielen der Dokumentation.
Plattformen & Cloud
Ein .NET-10-SDK ohne Druckertreiber, das Sie mit dotnet publish wie jede andere Abhängigkeit ausliefern: unter Windows, Linux und macOS, im IIS, in Docker-Containern und im Kubernetes-Cluster, on-premises oder in der Cloud wie Azure und AWS.
Eine .NET-10-Assembly auf Basis von SkiaSharp und HarfBuzz. Die automatisierten Tests laufen auf Windows 11, macOS und Linux grün. Kein Druckertreiber und kein GUI nötig.
Getestet in den .NET-Images für Debian, Ubuntu Chiseled und Azure Linux 3.0 (Distroless & NativeAOT). Selbst ein vorhandenes NAS wie eine Synology DS923+ (Container Manager) oder ein Raspberry Pi wird damit ohne Zusatzpakete zum lokalen Labelprint-Server.
ASP.NET-Core-Beispiel mit Streaming-Endpunkten, einer begrenzten Queue (Channel + BackgroundService) und parallelen Workern.
Dockerfile.server im Lieferumfang: Distroless-Image, läuft ohne Root-Rechte, mit /health-Endpunkt (oder als NativeAOT auf runtime-deps:10.0-noble-chiseled-extra ab ~79 MB).FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build WORKDIR /src COPY . . RUN dotnet publish samples/WebApiDemo -c Release -o /app FROM mcr.microsoft.com/dotnet/aspnet:10.0-azurelinux3.0-distroless WORKDIR /app COPY --from=build /app . ENTRYPOINT ["dotnet","WebApiDemo.dll"]
kind: Deployment spec: replicas: 2 template: spec: containers: - name: label-api resources: requests: { cpu: 500m, memory: 512Mi } limits: { cpu: "1", memory: 1Gi } readinessProbe: httpGet: { path: /health, port: 8080 } --- kind: HorizontalPodAutoscaler spec: metrics: - type: Resource resource: name: cpu target: { type: Utilization, averageUtilization: 70 }
Performance
Alle Zahlen sind gemessen, nicht geschätzt: Release-Build, .NET 10, Apple M3 Max (10 Performance- + 4 Effizienzkerne). Die Benchmarks liegen im Repository bei.
Ein Druckauftrag: Start-Label + 100.000 Sendungs-Labels + End-Label, Schnitt nur nach dem letzten Label. 14 Kerne, samples/PerfTest.
| Szenario | Zeit | Labels/s | Größe | Speicher (Heap) |
|---|---|---|---|---|
Objekte → ZPL, gespeichertes Format (^DF/^XF) | 0,73 s | 136.000 | 14,7 MB | 24 MB |
| Objekte → ZPL, volles Format je Label | 0,39 s | 256.000 | 29,1 MB | 24 MB |
EF Core / SQLite AsAsyncEnumerable() → Datei | 0,57 s | 176.000 | 14,7 MB | 29 MB |
| LiteDB-Query → Datei | 0,50 s | 202.000 | 14,7 MB | 64 MB |
| PNG-Vorschau sequenziell (799 × 480 px, Graustufen) | 3,4 min | 490 | 18,2 MB / 2.000 | 84 MB |
| PNG-Vorschau parallel (14 Kerne) | 24,8 s | 4.033 | 17,1 MB / 2.000 | 106 MB |
Die ZPL-Erzeugung ist praktisch kostenlos und streamt mit konstantem Speicher. Das gespeicherte Format halbiert die Datenmenge zum Drucker (14,7 statt 29,1 MB).
ASP.NET-Core-Minimal-API aus samples/WebApiDemo: 14 Kerne, Server-GC, 14 Worker, Label 100 × 60 mm bei 203 dpi. Client und Server im selben Prozess.
| Szenario | Labels/s | MB/s | p50 | p95 | GC-Heap |
|---|---|---|---|---|---|
| JSON-Payload → ZPL | |||||
| 1.000 Datensätze/Request | 62.857 | 20,3 | 16,2 ms | 16,7 ms | 178 MB |
| 10.000 Datensätze/Request | 112.484 | 36,4 | 76,1 ms | 136,9 ms | 183 MB |
| 100.000 Datensätze/Request | 186.572 | 60,5 | 527,5 ms | 565,2 ms | 414 MB |
| DB-Streaming → ZPL | |||||
| 10.000 Datensätze | 151.744 | 49,1 | 69,6 ms | 73,1 ms | 361 MB |
| 100.000 Datensätze | 199.102 | 64,6 | 504,3 ms | 505,2 ms | 372 MB |
| Gleichzeitige Clients | |||||
| JSON 1k, 1 Client | 196.112 | 63,4 | 4,8 ms | 8,6 ms | 404 MB |
| JSON 1k, 4 Clients | 240.453 | 77,7 | 16,4 ms | 21,7 ms | 404 MB |
| JSON 1k, 16 Clients | 155.344 | 50,2 | 100,8 ms | 120,8 ms | 419 MB |
| DB 10k, 4 Clients | 215.699 | 69,7 | 186,2 ms | 202,4 ms | 395 MB |
| DB 10k, 16 Clients | 179.860 | 58,2 | 878,0 ms | 907,6 ms | 408 MB |
| Vorschau (50 Labels/Request) | |||||
| PDF, 1 Client | 583 | 5,0 | 87,0 ms | 94,0 ms | 267 MB |
| PNG (zip), 1 Client | 484 | 4,6 | 108,3 ms | 108,7 ms | 269 MB |
| PDF, 14 Clients | 5.085 | 43,5 | 131,8 ms | 154,4 ms | 472 MB |
| PNG (zip), 14 Clients | 3.995 | 38,1 | 162,0 ms | 188,1 ms | 473 MB |
| Job-Queue (alle Jobs gleichzeitig eingereicht, Latenz inkl. Wartezeit) | |||||
| 256 × JSON 1k → ZPL (153 Jobs/s) | 153.438 | 49,6 | 98,8 ms | 365,5 ms | 885 MB |
| 64 × DB 10k → ZPL (18,6 Jobs/s) | 186.361 | 60,3 | 2.236,5 ms | 3.411,1 ms | 828 MB |
| 64 × JSON 50 → PDF (104 Jobs/s) | 5.396 | 46,2 | 345,2 ms | 445,6 ms | 467 MB |
Die ZPL-Erzeugung sättigt bei 199.000 Labels/s (ab 4 parallelen Requests), weitere Clients erhöhen nur die Latenz. Rendern kostet 40× mehr und skaliert mit den Kernen.
Vorher (heller Balken): 499 → 1.826/s, maximal 4,5× bei 8 Threads.
Vorher wurde Text mit mehr Threads langsamer (0,6× bei 8 Threads), weil Skias Glyph-Cache global sperrt.
Gemessen mit RenderBench -- 150 scale auf dem M3 Max. Glyphen landen einmal pro Schrift und Größe in einem sperrfreien Cache, so entfallen die globalen Sperren von SkiaSharp.
Pro Label 100 × 60 mm bei 203 dpi. Graustufen- bzw. 1-Bit-PNG statt RGBA, direkt gezeichnete ^GB-Rahmen, sperrfreier Glyph-Cache.
| Messung | Vorher | Jetzt | Verbesserung |
|---|---|---|---|
| Rendern zu Bitmap | 1,28 ms | 0,39 ms | −70 % |
| Rendern + PNG | 8,19 ms | 1,86 ms | −77 % |
| PNG-Größe | 18 KB | 9 KB | −50 % |
| 100.000 Vorschauen sequenziell | 14,5 min | 3,4 min | −77 % |
| 100.000 Vorschauen parallel | 2,2 min | 25 s | −81 % |
| Rendern + PNG, 10 Threads | 1.826/s | 5.022/s | 2,8× |
| Nur Text, 8 Threads | 3.162/s | 42.434/s | 13,4× |
| Arbeitslast | Labels | Speicher |
|---|---|---|
| Dauertest, kleine Labels, parallel | 1.000.000 | RSS 128–138 MB · GC-Heap 2–3 MB |
| Dauertest, 4 × 6″-PNGs, 14 Threads | 1.000.000 | RSS 438–481 MB |
| ZPL-Streaming aus Objekten | 100.000 | Heap 24 MB |
| Streaming aus EF Core / SQLite in eine ZPL-Datei | 100.000 | Heap 29 MB |
| Streaming aus LiteDB in eine ZPL-Datei | 100.000 | Heap 64 MB |
Release-Build, .NET 10, Apple M3 Max (10 Performance- + 4 Effizienzkerne). Zusätzlich als NativeAOT-Container (runtime-deps:10.0-noble-chiseled-extra, ~79 MB) auf einem Synology DS923+ NAS (AMD Ryzen R1600, 2 Kerne / 4 Threads) gemessen: 237.428 Labels/s Parsen, 1.233 Labels/s Bitmap-Rendern und 295 PNG-Labels/s (> 17.500 PNGs/min). Alle Messungen lassen sich mit einem Befehl wiederholen.
# 100.000-Label-Druckauftrag dotnet run -c Release --project samples/PerfTest -- 100000 # Thread-Skalierung (label|text|barcode|box|empty) dotnet run -c Release --project samples/RenderBench -- 150 scale
Datenquellen
Die Datenbindung arbeitet mit jedem IEnumerable<T>, IQueryable<T> oder IAsyncEnumerable<T>. Filter und Sortierung laufen in der Datenbank, die Etiketten werden gestreamt. Damit funktionieren alle EF-Core-Provider und jeder Datenbank-Treiber mit LINQ.
über EF Core, offizielle .NET-Treiber oder eigene Objekte
Beispiel: Logistik-Druckauftrag → Zwölf Sendungen aus SQLite, per EF Core in einen Druckauftrag
Quality Gates
Eine kaputte Vorlage, die erst im Betrieb auffällt, wird teuer: Barcodes, die an der Rampe nicht scannen, Linien, die stehen, Sendungen, die der Carrier zurückweist, und Fehlerwellen über alle Standorte. zplCore prüft jede Vorlage dort, wo sie entsteht: im Commit, im Pull Request, in der Pipeline und schon beim Container-Build.
Vorlage in Git geändert
Vorher-, Nachher- und Diff-Bilder im PR-Kommentar, Befunde als SARIF in Code Scanning
zplcore check mit JUnit-XML und SARIF; Exit-Code 1 stoppt den Build
Prüf-Stufe im Dockerfile: Kein Image entsteht mit einer kaputten Vorlage
Virtueller Drucker mit Cutter und RFID: Schnitte, EPCs und VOID wie am echten Gerät
Nur geprüfte und freigegebene Vorlagen
--min-grade--baseline: was der PR an Daten und Positionen ändert^MM, ^PQ, ~JK, ^CN# echte Ausgabe, gekürzt PASS templates/dhl-100x150.zpl FAIL templates/express-100x150.zpl FAIL comply gs1-logistic :38:1 error ZPL3104 X-dimension 0.375 mm < 0.495 mm :38:1 error ZPL3105 bar height 13.0 mm < 31.75 mm FAIL scan-proof :32:1 error ZT1301 QR Code grade D, required B ok printer ZD421d (ZD421d-203) FAILED (fail-on error) · exit 1
zplcore-mcp, erklärt die Befunde und schlägt die Korrektur als Commit vor.MCP-Werkzeuge:complyverifyprinter_checkrenderdiff
# Exit-Code 1 bei Fehlern, Berichte für die Pipeline
zplcore check templates/ --pack gs1-logistic \
--verify --min-grade B --printer ZD421d-203 \
--junit out/labels.junit.xml --sarif out/labels.sarif# Build-Stufe: Vorlagen prüfen, bevor ein Image entsteht FROM mcr.microsoft.com/dotnet/sdk:10.0 AS label-gate WORKDIR /src COPY nuget.config ./ COPY .config/ .config/ COPY templates/ templates/ RUN dotnet tool restore \ && dotnet zplcore check templates/ --pack gs1-logistic \ --verify --min-grade B --printer ZD421d-203 FROM mcr.microsoft.com/dotnet/aspnet:10.0 # nur geprüfte Vorlagen landen im Image COPY --from=label-gate /src/templates /app/templates
[Fact] public void Versandetikett_ist_druck_und_scanfest() { ZplAssert.LabelFile("templates/dhl-100x150.zpl") .NoOverlaps().NoClipping() .Complies(CompliancePacks.Gs1LogisticLabel) .FitsPrinter(PrinterProfiles.Get("ZD421d-203")) .Barcode("SSCC").Decodes("(00)390012340047110001") .HasGrade(atLeast: 'B'); }
Eine kleine Änderung an ^MM oder ^PQ schneidet plötzlich jedes Etikett oder gar keins; ein festes ^RF schreibt denselben EPC auf jede Kopie. Beides fällt sonst erst an der Linie auf. Im Gate steht es vorher fest.
^MMC, ^PQ6,3)3156…8000000, das Gate stoppt(00)390012340047110001zplcore serve --rfid) und RFID-Prüfung. Auch geprüft: EPC passt zum Barcode (ZPL3904), Speicherbank und PC-Bits, ^RS/^HV, Sperren ohne Passwort.// Schnitte: wo der Cutter schneidet var plan = ZplCutPlan.Analyze(zpl); Assert.Equal([2, 5], plan.CutAfter); // nach Etikett 3 und 6 Assert.Empty(plan.Diagnostics); // RFID: EPC passt zum Barcode, kein EPC doppelt ZplAssert.Label(zpl) .Complies(CompliancePacks.Rfid) .FitsPrinter(PrinterProfiles.Get("ZT411-203") .WithOptions(PrinterOption.Cutter | PrinterOption.Rfid) .AsPrinterFit());
# CI: RFID-Paket im Gate, EPC je Etikett anzeigen zplcore check templates/ --pack gs1-logistic,rfid zplcore rfid simulate templates/palette.zpl # Staging: Drucker mit Cutter und RFID simulieren zplcore serve --profile ZT411-203 --option cutter,rfid \ --rfid --cut-marks
Heute im SDK: ZplCore.Testing, zplcore check und zplcore-mcp. Die GitHub Action liegt im Lieferumfang (tools/github-action); die Veröffentlichung im Marketplace als zplcore/label-check ist vorgesehen. Compliance und Note sind Vorprüfungen, keine Zertifizierung.
Etiketten-Tests →zplcore check →GitHub Action →Compliance →Scan-Proof →Printer Twin →MCP-Server →
KI & AutomationMCP
Mit dem MCP-Server zplcore-mcp arbeiten KI-Agenten wie Claude Code, Claude Desktop, GitHub Copilot in VS Code und Cursor direkt mit der zplCore-Engine: ZPL schreiben, rendern, Prüfbericht lesen, korrigieren, so lange, bis das Etikett stimmt. Offline, auf Ihrem Rechner, über das Model Context Protocol.
Erstelle für diese Sendung ein GS1-Versandetikett 100 × 150 mm und prüf es gegen die GS1-Logistikregeln.
lint0 Diagnosencomplygs1-logistic2 Fehler · 11 HinweiseZPL3104 SSCC: X-Dimension 0,375 mm < 0,495 mm · ZPL3105 Balkenhöhe 13 mm < 31,75 mm^BY4 und 270 Dots Höhe, Schrift ab 3 mm, Layout angepasst.complygs1-logistic0 Fehler · 0 Warnungen · 0 Hinweiseverify3 von 3 Barcodes gelesen · Note ArenderPNG · 100 × 150 mm · 203 dpi
0 Fehler · alle Barcodes Note A
renderfill_templateformatconvert_eplimport_labellift_svglintdiffcomplyverifyprinter_profilesprinter_checkprint_estimatecut_planextractredactgs1_link_buildgs1_link_parsegs1_migraterfid_encoderfid_decoderfid_checklist_symbologiesdescribe_symbologyexplain_commandget_limitssandbox-exec-Sandboxzplcore check und der GitHub Action# Claude Code: Server im aktuellen Projekt eintragen
claude mcp add zplcore -- zplcore-mcp
zplcore-mcp ist im SDK als dotnet-Tool enthalten (.NET 10). Installation und die Konfiguration für Claude Desktop, VS Code und Cursor stehen in der Doku.
zplCore Server · DockerDemnächst
Der zplCore Server soll die Engine als fertigen Container bereitstellen: Die Vorlagen liegen beim Server, Ihre Anwendung schickt nur noch die Daten (oder der Server holt sie über eine benannte Abfrage selbst) und erhält ZPL, PNG oder PDF zurück, auf Wunsch direkt gedruckt. Die Messwerte stammen aus unserem NativeAOT-Test; der Funktionsumfang ist geplant.
gemessen im NativeAOT-Test auf linux/arm64
einmal ablegen oder dynamisch per HTTP laden
versand/dhl-100x150Label.ToJson): einmal entwerfen, in App und Container nutzenmitschicken oder abholen lassen
EF Core nutzen Sie direkt in Ihrer .NET-App mit dem SDK; im Container genügen benannte Abfragen, ganz ohne Code.
streamen, drucken, ablegen
Accept-Headerwächst mit der Last
/health, /ready, /metrics (Prometheus) und OpenTelemetryzplcore.yaml oder Umgebungsvariablen, dazu ein Helm-Chart# Vorlagen aus ./templates bereitstellen docker run -p 8080:8080 \ -v ./templates:/templates:ro \ zplcore/server # Daten rein, ZPL raus curl -X POST \ localhost:8080/v1/labels/versand/dhl-100x150 \ -H 'Accept: application/vnd.zpl' \ -H 'Content-Type: application/json' \ -d '{"name":"Anna Huber","city":"Wien"}'
/docsdocker run / podman runKeine Preise, kein Kauf: Wir melden uns, sobald die erste Version bereitsteht.
Ein Paket statt vier
Viele .NET-Teams kaufen für Etiketten gleich mehrere SDKs: einen ZPL-Emulator, einen EPL-Emulator, einen Label-Designer und eine Barcode-Bibliothek. zplCore.com übernimmt ZPL-Rendering, EPL-Rendering, Label-Design und Barcode-Erzeugung in einem SDK, in einer Assembly.
| Einsatzfall | Üblicherweise | zplCore.com |
|---|---|---|
| ZPL → PNG/PDF-Vorschau | ZPL-Emulator-SDK | ZplRenderer |
| EPL2 → Bild, EPL → ZPL-Migration | EPL-Emulator-SDK | EplRenderer · ToZpl() |
| Etiketten im Code entwerfen, Daten binden, drucken | Label-Designer-SDK | Labels.Label · PrintJobTemplate |
| Barcodes als Bild/Vektor, GS1-Prüfung | Barcode-SDK | Barcodes.Barcode · Gs1 |
Sie wechseln von einem anderen SDK? zplCore.com ist keine 1:1-Kopie fremder APIs und hat nicht jede Funktion. Schicken Sie uns Ihre ZPL-Dateien und Anforderungen, dann prüfen wir die Abdeckung vor dem Kauf (siehe auch bekannte Grenzen).
Weltschriften
TrueType-Schrift in den Druckerspeicher laden oder als Grafik drucken. Diese Ausgaben stammen direkt aus der Engine.
Code
var renderer = new ZplRenderer(new ZplRenderSettings { Dpi = 203 }.WithLabelSizeMm(100, 150)); List<byte[]> pngs = renderer.ProcessCommands( "^XA^FO50,50^A0N,40,40^FDHallo Welt^FS^BY2^FO50,120^BCN,80^FD12345^FS^XZ"); renderer.Settings.OutputFormat = ZplOutputFormat.Pdf; File.WriteAllBytes("preview.pdf", renderer.ProcessFile("labels.zpl")[0]);
using ZplCore.Labels; var job = PrintJobTemplate.FromFiles("templates/leading.json", "templates/shipping.json", "templates/trailing.json"); job.JobName = "Tour 7"; job.KeyField = "TrackingNo"; // erster/letzter Schlüssel auf dem End-Label job.CutAfterLastLabel = true; // Schnitt nur nach dem letzten Label job.StoredFormatName = "R:SHIP.ZPL"; // Vorlage einmal, danach nur Feldwerte string zpl = job.For<Shipment>().ToZpl(db.Shipments.Where(s => !s.Printed).Take(50).ToList()); File.WriteAllText("job.zpl", zpl); // 52 Labels in EINER Datei
# samples/WebApiDemo – ASP.NET Core Minimal API dotnet run -c Release --project samples/WebApiDemo # 50.000 Sendungen aus EF Core/SQLite als ZPL streamen curl 'localhost:5080/api/jobs/db/zpl?country=AT&take=50000' -o at.zpl # PDF-Vorschau aus JSON-Datensätzen curl -X POST 'localhost:5080/api/jobs/preview?format=pdf' -H 'Content-Type: application/json' -d @records.json -o preview.pdf # Asynchron über die Queue: 202 Accepted, 429 wenn voll curl -X POST localhost:5080/api/queue -H 'Content-Type: application/json' -d '{"db":{"country":"AT","take":20000},"output":"zpl"}'
var epl = new EplRenderer(new ZplRenderSettings { Dpi = 203 }); List<byte[]> labels = epl.ProcessFile("label.epl"); string zpl = epl.ToZpl(File.ReadAllText("label.epl")); // EPL-Formulare nach ZPL migrieren var bc = new ZplCore.Barcodes.Barcode { Symbology = ZplCore.Barcodes.Symbology.Gs1_128, Code = "(01)09521234543213(10)LOT42", Unit = ZplCore.Barcodes.BarcodeUnit.Millimeter, BarWidth = 0.33, BarHeight = 20, }; File.WriteAllText("gs1.svg", bc.ToSvg());
Beispiel: Logistik-Druckauftrag
Zwölf Sendungen einer Zustelltour liegen in einer SQLite-Datenbank. Eine EF-Core-Abfrage liefert sie, PrintJobTemplate erzeugt daraus einen Auftrag in einer ZPL-Datei: Start-Label, zwölf Versandlabels im Format 100 × 150 mm (Absender, Empfänger, Service-Feld, Routing-Code, SSCC als echter GS1-128 mit FNC1, Tracking-QR und Code 128, Zähler 1/12) und End-Label mit Summen und Schnitt. Vorlagen sind die JSON-Dateien aus samples/templates, das Programm liegt unter samples/LogisticsShowcase.
var job = PrintJobTemplate.FromFiles("leading.json", "shipping.json", "trailing.json"); job.JobName = "Tour 17 · Wien Süd"; job.KeyField = "TrackingNo"; // erste/letzte SSCC auf dem End-Label job.CutAfterLastLabel = true; // Schnitt nach dem End-Label var shipments = db.Shipments.AsNoTracking() // EF Core, von SQLite ausgeführt .Where(s => s.Tour == 17 && !s.Printed) .OrderBy(s => s.RoutingCode).ThenBy(s => s.TrackingNo) .ToList(); job.Leading.Expressions // Kopf-Daten für das Start-Label .SetCustomVariable("FIRST_SSCC", shipments[0].TrackingNo) .SetCustomVariable("LAST_SSCC", shipments[^1].TrackingNo) .SetCustomVariable("TOTAL_WEIGHT", $"{shipments.Sum(s => s.WeightKg):0.0} kg"); string zpl = job.For<Shipment>() .Map("Total", s => $"{s.WeightKg:0.0} kg") .ToZpl(shipments); // Start-Label + 12 Versandlabels + End-Label File.WriteAllText("tour17.zpl", zpl);
// shipping.json (Auszug), 100 × 150 mm { "type": "text", "dataField": "Service", "fontSize": 17, "reverse": true, "x": 62, "y": 7.5 }, { "type": "text", "dataField": "RoutingCode", "font": "0", "fontSize": 40, "width": 97, "alignment": "Center", "x": 1.5, "y": 67 }, { "type": "barcode", "symbology": "QrCode", "expression": "\"https://track.zplcore.com/s/\" + [TrackingNo]", "barHeight": 4, "x": 3, "y": 98 }, { "type": "text", "expression": "[PAGE_NUMBER] + \"/\" + [TOTAL_PAGES]", "fontSize": 16, "x": 74, "y": 112 }, { "type": "barcode", "symbology": "Gs1_128", "expression": "\"(00)\" + [TrackingNo]", "moduleWidth": 3, "barHeight": 13, "humanReadable": true, "x": 20, "y": 125.5 }
Preise
pro Entwickler, einmalig
bis 5 Entwickler, einmalig
bis 5 Entwickler, einmalig
auf Anfrage
Alle Angebote richten sich ausschließlich an gewerbliche Kunden (B2B). Preise netto zzgl. gesetzlicher USt. Verlängerung von Updates & Support: 40 % des Listenpreises pro Jahr. Ohne Verlängerung dürfen Sie die zuletzt erhaltene Version unbegrenzt weiter nutzen. Auf Wunsch ist ein Jahresabo möglich.
FAQ
Pro Entwickler, der mit zplCore.com programmiert. Produktions-, Test- und Build-Server zählen nicht als Entwickler. Die Lizenz ist dauerhaft (perpetual) und enthält 12 Monate Updates. Lizenzen werden ausschließlich an gewerbliche Kunden (B2B) vergeben.
Ja, ab der OEM-/SaaS-Lizenz in Ihren eigenen Anwendungen und Diensten. Ausgenommen ist ein Weiterverkauf als eigenständiges Entwickler-SDK.
E-Mail-Support durch das Entwicklerteam. Die Reaktionszeit hängt von der Lizenzstufe ab. Bugfixes kommen mit den regulären Updates.
zplCore.com ist eine unabhängige Implementierung auf Basis der öffentlichen ZPL-II-Spezifikation und der Symbologie-Standards. Sie enthält keinen Code anderer kommerzieller Anbieter. Verwendete Open-Source-Komponenten (z. B. aus BWIPP/bwip-js und zint, MIT- bzw. BSD-Lizenz) sind in THIRD-PARTY-NOTICES.md dokumentiert.
Nicht umgesetzt sind Pharmacode 2D, Response Plus PostMatrix und HIBC nach ISO/IEC 15434, für die es keine öffentliche Spezifikation gibt. Deutsche Post BZL und JABCode sind experimentell. Zebras residente Schriften sind proprietär und werden durch Roboto Condensed bzw. DejaVu ersetzt, kalibriert auf Zebra-Metriken. Wer identische Glyphen braucht, registriert die Original-TTF. Die Drucker-Transporte seriell, USB, Windows-Spooler und CUPS sind nicht auf Hardware getestet. Compliance-Pre-Check, Scan-Proof und Printer Twin prüfen das gerenderte Etikett: Sie ersetzen weder die Freigabe durch Carrier oder Behörden noch ein Barcode-Prüfgerät am gedruckten Etikett. Die Schwärzung ist regelbasiert und ohne Vollständigkeitsgarantie, Text in Bildern wird nicht gelesen. Vector-Lift setzt Text in Font 0 statt der Originalschrift, und Text, der im PDF nur als Umriss vorliegt, bleibt Grafik (keine OCR). Label-Vorlagen gibt es nur als JSON.
Ja. Schreiben Sie uns, dann senden wir Ihnen eine Testversion. Gern prüfen wir auch Ihre eigenen ZPL-/EPL-Dateien.
Testversion
Testversion, Angebot oder Migrationscheck: Schicken Sie uns eine kurze Nachricht.
Lieber per E-Mail?
Ihre Anfrage ist bei uns eingegangen. Wir melden uns in Kürze per E-Mail bei Ihnen.