How to print the Euro Symbol €?

[atrudl]

The Euro Symbol is not available in any CodePage

[lucdhaenen]

Indeed, I need it for our receipts...
Now my code looks like this:

e.PrintLine((item.Aantal + " x " + item.VKP + "€") + " = " +item.Totaal.ToString() + "€")

When I print under Codepage pc437 it gives me 1/4...

Pls advise

[lukevp]

Hey @atrudl @lucdhaenen sorry for the delay. The euro is available on several codepages.

The problem both of you are running into is that C# strings are Unicode, so you are able to declare a string with the value "€" in C#, but unfortunately, that value does not correctly map to an ASCII 8-bit value that's printable using the standard 7-bit + extended codepages. See here for more information. This is a 2 byte Unicode string.

In order to print a Euro symbol, you must switch to a code page that supports that, then print a character with the relevant ASCII value. Here is an example:

private static void PrintEuro()
{
    var EURO = new byte[] { 0xD5 };
    printer.Write(ByteSplicer.Combine(
        e.CodePage(CodePage.PC858_EURO),
        EURO,
        e.CodePage(CodePage.PC437_USA_STANDARD_EUROPE_DEFAULT)));
}

Switching back to the standard codepage is optional. If you don't need the extended USA/Europe codepage, you could just switch to PC858_EURO and use that for your whole receipt.

I have just pushed a new build of the library that has a code page tester, option 8. Please give it a try and print index 17 (PC858_EURO) and you will see the Euro there in the list. Here is the example output of the PC858_EURO codepage with the Euro symbol highlighted.

I think this could be made easier to use if the PrintLine function could do CodePage switching automatically - i.e. it could accept Unicode strings and convert them to ASCII runs with CodePage switch commands embedded. @igorocampos do you have any thoughts on this? Feature creep or helpful functionality?

We could have PrintLine replace known unicode characters and allow it to swap codepages as necessary, but that might result in a LOT of CodePage switching potentially (up to each character, even). Might not necessarily be an issue though.

[igorocampos]

@lukevp, I don't have any function helpers that "auto-convert" from Unicode to ASCII... I think implementing the built-in mapping with CodePage switches would be the way to go. However I wonder how people actually do with Chinese/Japanese Characters, since there are thousands of characters to be mapped... Maybe a research on that would give better ideas?

[igorocampos]

@lukevp I've searched in the repo a little bit about that. And perhaps we don't need to change the printer's codepage at all.
See this and this

If we give to the user the possibility to choose the proper encoding when converting from string to byte[], they can choose whatever encoding page to use for retrieving the right byte. At least that's what I understood, especially from the second link.

[adamcosby85]

Even though this is closed - i thought it was worth mentioning my findings on this.

I have been stuck on this all day and I found that the reason it wasn't working for me was because the CodePage ints are different for my printer (Munbyn 80mm). Annoying as it is, the CodePage.PC858_EURO in this solutions maps to int 19. However, when I did a self-print on my printer I was able to get its CodePage and PC858 actually maps to int 31 on my printer which is TCVN3_VIETNAMESE_U.

This is a little annoying because I cannot pass in my own enum into the e.CodePage method with the correct int's so for now I need to setting for actually encoding using the following code:

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
Encoding enc = Encoding.GetEncoding("IBM00858");

string unicodeStringTest = "éçà€éçà€éçà€éçà€éçà€";
var testBytes = enc.GetBytes(unicodeStringTest);

printer.Write(ByteSplicer.Combine(
  e.CodePage(CodePage.TCVN3_VIETNAMESE_U), // This is actually PC858 (19) but my printer was PC858 as 31
  tempBytes
));

I am not sure if anything can be done about this because other printers might have their own mapping and it does make our code base a little confussing. I tried to generate my own enum but I cannot use it on the e.CodePage method for obvious reasons - something as simple as a int input would be good as an alternative to the actual CodePage enum you have for cases like mine.

Either way - the CodePage test you did was really useful @lukevp but note to people to be sure the CodePage mapping on the printer matches those in the binary - took hours and three rolls of paper for me to figure it out :)