I hope you are well.
I am using a printer that uses the JPOS driver. I've got everything working, but I've come across a peculiar bug.
When printing certain special characters "£" and "€", at first they print out correctly as expected. But if during a receipt print we call the escape sequence \u001b|N (The escape command for Restoring printer characteristics to normal condition. Page 244. https://docplayer.net/30157845-Java-for-retail-pos-programming-guide-version-1-2-march-27-international-standard.html), it seems like the code page (or something) also gets reset.
After using this escape sequence, "£" becomes "ú" and "€" becomes "Ç".
For clarity, I only use this escape sequence as I have a need to bold certain text (using escape sequence \u001b|bC), and the only way to un-bold it seems is to use the "restore to normal condition" escape sequence (\u001b|N). I have tested and verified that this issue occurs even if I call \u001b|N on its own, without bolding beforehand.
If it helps, the printer is an HP Engage One thermal receipt printer.
Does anybody have any idea why this is happening, and how I can prevent this?
An example string that is affected:
Monetary value: £1.30
\u001b|bCWe bold this text\u001b|N
Another monetary value, that now displays incorrectly: £4.20
I was originally using codepage 1252, and decided to set the code page to 850, now the codepage is no longer being reset. In the end, this indeed seems to have been some kind of bug - unless the Printer's default codepage is 850, then that answers why it was getting reset to that - though seems like bad design if you can reset codepage to default via escape commands, but can't then set it back the same way.
(Note that the above codepage numbers get set in the Java code used to interface with the printers)