Früher oder später soll eine Web-Anwendung ein Etikett auf
einem Thermodrucker ausgeben, und der erste Versuch ist immer derselbe: aus
JavaScript einen Socket zum Drucker öffnen. Das geht nicht — und warum es
nicht geht, zeigt direkt die Muster, die funktionieren.
Warum der direkte Weg nicht funktioniert
Roher Thermodruck heißt: Bytes auf TCP-Port 9100 schreiben. Browser
stellen bewusst keine API für beliebige TCP-Sockets bereit — Seiten-
JavaScript spricht HTTP, WebSocket und WebRTC, und alle drei brauchen einen
kooperierenden Server auf der Gegenseite. Ein Etikettendrucker auf Port
9100 ist kein solcher Server: kein HTTP, kein Handshake. Die Einschränkung
ist eine Sicherheitsgrenze, kein fehlendes Feature; keine Bibliothek umgeht
sie.
Muster 1 — der Server leitet weiter
Der Browser schickt das Etikett an Ihr Backend; das Backend öffnet den
Socket zum Drucker und leitet die Bytes weiter. Für Lager- und
Backoffice-Anwendungen ist das die Standardantwort: Drucker und Server
liegen im selben Netz.
Gut: keine Software auf dem Arbeitsplatz, Protokoll und
Wiederholung an einer Stelle, Druckerdaten erreichen den Browser nie.
Preis: der Server muss den Drucker erreichen können —
steht der Drucker im Kundennetz und Ihr Dienst in der Cloud, fällt das
Muster aus.
Muster 2 — ein lokaler Helfer am Arbeitsplatz
Neben dem Browser läuft ein kleines Programm, lauscht auf localhost, und
die Seite schickt ihm das Etikett per HTTP; der Helfer schreibt auf Port
9100. So arbeiten die meisten "Webdruck"-Werkzeuge der Hersteller, und es
ist das einzige Muster, das einen für den Server unsichtbaren Drucker
erreicht.
Gut: funktioniert mit Druckern im Netz des Nutzers,
auch bei cloud-gehosteten Anwendungen.
Preis: auf jedem Arbeitsplatz muss etwas installiert
und aktuell gehalten werden; für den Aufruf von localhost muss der Helfer
CORS und auf HTTPS-Seiten die Mixed-Content-Regeln bedienen.
Muster 3 — rendern und den Druckdialog des Browsers nutzen
ZPL in Bild oder PDF wandeln, anzeigen, und der Bediener druckt über den
normalen Treiber. Keine Sockets.
Gut: läuft überall, ohne Installation; die richtige
Antwort für gelegentlichen Druck oder wenn der "Drucker" in Wahrheit ein
Bürolaser ist.
Preis: der Treiber rastert die Seite, Barcodekanten
hängen davon ab, und Seitenskalierung kann das Etikett stumm
umdimensionieren. Für scannbare Barcodes in Masse sind Muster 1 und 2
sicherer — die Begründung steht in
PDF oder ZPL.
Was Sie auch wählen: erst das Etikett ansehen
Port 9100 kennt kein Rückgängig — sobald der Auftrag ankommt, bewegt der
Drucker Material. Den Auftrag vorher im Browser zu rendern kostet nichts
und fängt die strukturellen Probleme ab: Felder außerhalb des Etiketts, ein
fehlender Abschluss, nicht kodierbare Barcodedaten. Fügen Sie ihn in den
ZPL-Viewer ein oder rufen Sie die
Render-API aus demselben Backend auf, das später
sendet. Die Betriebssystem-Seite der Auslieferung steht in
ZPL an einen
Netzwerkdrucker senden.
Labelixa DirectPrint
Werden Ihre Etiketten in Labelixa erzeugt oder gespeichert, ist der DirectPrint-Agent das fertige lokale Hilfsprogramm: ein kleines Programm auf einem Rechner im Netz des Druckers, das Druckaufträge von der API abholt und an den Drucker übergibt — über das Netzwerk oder über die Druckwarteschlange eines USB-Druckers. Es öffnet keinen eingehenden Port. Download und Einrichtung: /de/download
Kann JavaScript ZPL direkt an einen Drucker senden?
Nein. Roher Thermodruck schreibt Bytes auf TCP-Port 9100, und Browser bieten keine API für beliebige TCP-Sockets — nur HTTP, WebSocket und WebRTC, die alle einen kooperierenden Server brauchen. Ein Drucker auf Port 9100 spricht keines davon. Das ist eine Sicherheitsgrenze; keine Bibliothek umgeht sie.
Wie drucken Web-Anwendungen dann ZPL?
Drei Muster: Das Backend leitet den Auftrag an Port 9100 weiter (Netzzugriff nötig), ein kleiner lokaler Helfer lauscht auf localhost und reicht weiter (Installation je Arbeitsplatz), oder das Etikett wird als Bild bzw. PDF gerendert und über den normalen Treiber gedruckt (ohne Installation, aber der Treiber rastert den Barcode).
