Garbled Characters
The layout is right, the text is in the right places, and the characters are wrong - accented letters turned into symbols, Cyrillic into line-drawing characters.
This is a code-page mismatch, and it is the single most common surprise when moving from a driver to raw ESC/POS.
Why it happens
ESC/POS text is bytes, not Unicode. A single byte means whatever the currently selected code page says it means. Your application encodes the text with some code page; the printer decodes it with whichever one it was last told to select. When the two disagree, every non-ASCII character comes out wrong while ASCII looks perfect - which is why the problem often hides until the first accented name.
The fix
Select the code page explicitly at the start of every job, and encode your text with the same one:
ESC t nselects the page, wherenis the printer's identifier for it -0for CP437,17(0x11) for CP866,46(0x2E) for Windows-1251.- Then encode your strings with that same page in your application, rather than sending UTF-8.
Do not rely on the printer's power-on default, and do not assume it survives between jobs.
Confirming what was sent
Switch on Raw Data for the document. Each element is shown with its raw bytes next to the parsed
command, and text is decoded with the code page in effect at that point - enough to tell a wrong
ESC t from text that was encoded wrongly before it ever left your application.
If the document contains no ESC t at all, that is the answer: your application never selected a page.
Still stuck?
Email support@virtual-printer.online with the printer's protocol and port, what your application sent, and what you expected to see.
Next pageFAQ →