Transports

Transports (CrossEscPos.Transports)

Desktop transports that feed an ESC/POS stream into a ReceiptPrinter the way a real device receives it — over TCP/IP, a serial port, or USB. They also implement IPrinterResponder, so the printer's status replies (DLE EOT, GS r, Automatic Status Back) are sent back over the same channel.

Desktop only. These use raw sockets, System.IO.Ports and libusb, which don't exist in the browser sandbox — a WASM host feeds ESC/POS in-page instead and doesn't reference this package.

flowchart LR
    host["POS app / client"] -->|ESC/POS bytes| t["NetServer / SerialServer"]
    t -->|FeedEscPos| printer["ReceiptPrinter"]
    printer -.->|status bytes via IPrinterResponder| t
    t -.-> host

Loading

TCP/IP server

Listens for connections and feeds whatever bytes arrive — how most modern POS software talks to a network receipt printer (port 9100 by convention).

using System.Net;
using CrossEscPos.Transports;

var tcp = new NetServer(printer);
tcp.Start(IPAddress.Any, 9100);
// … tcp.IsRunning, tcp.EndPoint …
tcp.Stop();

Serial server

Reads ESC/POS from an RS-232 / virtual serial port.

var serial = new SerialServer(printer);
serial.Start("/dev/ttyUSB0", baudRate: 9600);   // or "COM3" on Windows
// … serial.IsRunning, serial.PortName, serial.BaudRate …
serial.Stop();

To test serial without hardware, create a virtual serial bridge (a linked pair of ports) and point the server at one end and your client at the other — see the repository README's "Testing serial without hardware".

USB

UsbPrinter is a USB client (libusb) used to drive a real or emulated printer over a bulk endpoint. It needs the native libusb-1.0 at runtime (brew install libusb, apt install libusb-1.0-0; bundled on Windows).

Lifetime & threading

Start transports after constructing the printer and stop them on shutdown. Receive happens on a background thread, so if you bind printer state to a UI, set printer.UiDispatch (see Core Emulator → Threading).

tcp.Stop();
serial.Stop();

Browser transports (Web Serial / WebUSB)

The Blazor Web App has the browser equivalents of these transports — Web Serial and WebUSB — behind the same IPrinterResponder seam, so the receive → FeedEscPos → respond logic is identical to the desktop ones:

Browser	Desktop analogue	API
WebSerialTransport	SerialServer	Web Serial API
WebUsbTransport	UsbPrinter	WebUSB API

Both derive from a small WebTransportBase that owns the JS-interop plumbing: a DotNetObjectReference the JS calls back into with received bytes (OnDataReceived → EmulatorHost.FeedLive), and a fire-and-forget Send that writes status replies back out. Bytes cross the boundary as Uint8Array both ways (Blazor's native byte-array interop — no base64).

[device] --bytes--> transports.js (read loop) --Uint8Array--> OnDataReceived --> FeedEscPos
[device] <--bytes-- transports.js (write)     <--Uint8Array-- Send            <-- IPrinterResponder

Requirements: a Chromium browser (Chrome / Edge), a secure context (HTTPS or localhost), and a user gesture to open the device picker. Direction note: the browser is the host, so WebUSB reads a device's bulk IN endpoint (incoming ESC/POS) and writes status to bulk OUT — suited to devices/adapters that stream ESC/POS to the host.