> The ยฃ is printed just fine on some parts of the receipt!
> โจาบ๐ขส โคัแ ๐ฝแตส๊ช
Assuming the printer uses ESC/POS[0] (which is likely), the codepage is part of the printer's state. To change the code page, the driver sends a specific ESC command (<ESC t x> aka <1B 74 XX> where x/XX is the desired codepage byte) (none of which is "UTF8" incidentally) and you can change the codepage before each actually displayed character.
So it's the driver software fucking up and either misencoding its content (most likely) or selecting the wrong codepage. The ยฃ might be displayed correctly on the right side because it's e.g. hard-coded (properly encoded) while the product label is dynamic and when that was added/changed no care was taken with respect to properly transcoding. The printer absolutely doesn't care, it just maps a byte to a glyph according to the currently selected codepage.
[0] ESC because the protocol is based on proprietary ESCape codes[1], POS because the entire thing's a giant piece of shit
Thirty five years ago I started working for a company that made label printers and one of the common technical issues I had to deal with was pound signs not printing. It's quite funny that we still have the same issues after all that time.
Otoh twenty-seven years ago I spent a lot of time messing around with termcap and/or terminfo on various customer sites trying to get their terminals to display something other than gibberish. That's no longer really a thing, thank god, although I wryly note that there is, inevitably, a relevant O'Reilly book that I would have sold my grandmother for had I known about it.
Also simplicity (for the printer vendor), codepages means you just take your input byte and index into an array, UTF8 means you need to implement UTF-8 decoding (which is simple but not free and now you need to deal with decoding errors) and automatic check/swap of your raster maps in the printer. This is all logic which codepages foist onto the driver developer.
I believe that means it's correctly interpreting the Unicode, but there isn't a font that contains a character for that code. I think this is because the "official" Android font is patented, another layer of absurd crap that leads to many Unicode issues.
> โจาบ๐ขส โคัแ ๐ฝแตส๊ช
Assuming the printer uses ESC/POS[0] (which is likely), the codepage is part of the printer's state. To change the code page, the driver sends a specific ESC command (<ESC t x> aka <1B 74 XX> where x/XX is the desired codepage byte) (none of which is "UTF8" incidentally) and you can change the codepage before each actually displayed character.
So it's the driver software fucking up and either misencoding its content (most likely) or selecting the wrong codepage. The ยฃ might be displayed correctly on the right side because it's e.g. hard-coded (properly encoded) while the product label is dynamic and when that was added/changed no care was taken with respect to properly transcoding. The printer absolutely doesn't care, it just maps a byte to a glyph according to the currently selected codepage.
[0] ESC because the protocol is based on proprietary ESCape codes[1], POS because the entire thing's a giant piece of shit
[1] https://en.wikipedia.org/wiki/Escape_character#ASCII_escape_...