How It Works

The path a receipt takes

1. Your application opens a TCP socket to the printer's host and port and writes bytes.
2. The server reads them as a print job and runs them through the parser for that printer's protocol. Every command becomes a document element: a run of text with its styling, a barcode, an image, a cut, a drawer pulse, a status reply, or a note that a command was ignored.
3. The job ends when you close the connection, or after a short idle timeout if you leave it open.
4. The elements are stored and rendered. The browser draws the receipt from them, and the API can return the same elements for a test to assert against.

Because parsing happens on the server, the browser is a viewer rather than a participant. Nothing depends on a page being open while you print.

Why elements rather than a picture

A rendered image would answer only "does it look right". Elements answer "what did the printer actually receive": which command set the bold, which byte was ignored and why, what status the printer replied with. That is what makes the result useful in an assertion and in a bug report.

Every byte a job sends is accounted for — including bytes the printer ignores and commands cut short by a client that disconnected mid-command — so the elements of a document add up to the stream that produced it.

Emulated hardware, not just a parser

A printer here has state, and the state is visible to your application:

• Operational flags — paper out, paper near end, cover open, offline, error — set from the web interface or over the API, which change the status the printer reports.
• Cash drawer state, driven by ESC/POS pulses or set through the API.
• An optional receive buffer with a configurable capacity and drain rate. It fills as bytes arrive and empties at the rate you set; a job that outruns it is marked with a buffer overflow, and the printer reports itself busy or full while it holds data.

See CI/CD and automated tests for driving these from test code.