I used your exact font file and it works for me.
There is one issue with respect to WriteString() but it only relates to alignment.
(glcdfmt_right is broken for utf8 character strings - it will be fixed soon)
This issue will not affect normal printing.
What exactly were you doing and what wasn't working?
Keep in mind that there are several limitations.
You will be able to print literal strings that contain UTF8 characters.
i.e "Æøå"
You will not be able to print literal UTF8 characters directly.
i.e. 'Æ';
You will not be able to index into a string or treat it as array of characters if it contains
any UTF8 characters.
This is because of the way the compiler and some of the other libraries work.
The compiler will use the multi byte code when using UTF8 characters.
The rule for UTF8 is that anything above 0x7f gets multi-byte encoded.
For a string this results in there being more actual bytes in the string data than characters.
This works as long as the string processing routines understand UTF8 decoding.
The code I've added to openGLCD will process the UTF8 decoding so it will print the characters
correctly as long as openGLCD receives all the utf8 data.
Libraries like the Print class ignore the actual data in strings so openGLCD gets the full string and it all works.
For things like a literal character, the compiler creates a 16 bit "character" value as an integer
instead of an 8 bit character value.
This confuses the Print class library since it assumed nothing but 8 bit characters and
will interpret the 16 bit integer value as being a number rather than a character.
so If you call something like
GLCD.print('Æ');
The 'Æ' has a UTF8 value of 0xc386 which is what the compiler will pass to the Print class print() function as an integer rather
than a character.
The Print class will assume you are trying to print a 16 bit number and will convert it to an ASCII string of digit characters
which it hands character by character down to openGLCD.
openGLCD never sees the original 16 bit data.
If you use the xxprintf() code as an attempt to skip over the Print class integer processing by
using xxprintf() to create a string and then hand a string to opgnGLCD, it doesn't
work either.
So something like
GLCD.Printf("%c", 'Æ');
ends up printing the wrong character because the xxprintf() code in the AVR library also does not understand
UTF8 encodings so while all 16 bits (0xc386) got handed to the xxprintf() code, it thew away the upper 8 bits and printed
the wrong character code (0x86) instead of the proper decoded character code (0xc6).
You also can't cast the value to try to force it to be treated as a character rather than an integer.
i.e.
GLCD.print((char)'Æ');
While that will cause it to be treated as a character, only the lower 8 bits will be used and so
0x86 is handed down to openGLCD rather than the true decoded character code of 0xc6
You also have to be careful if you attempt to assign the literal to a char type like:
char c = 'Æ';
As that will only grab the lower 8 bits of the 16 bit UTF8 code.
So the character value in that case would be 0x86 instead of 0xc6.
There isn't much else I can do in the library other than offer a function or macro to do the character
UTF8 character decoding for convenience.
i.e. something like:
char c = GLCDUTF8('Æ');
or
char c = GLCD.utf8CharDecode('Æ');
GLCD.print(c);
You could also then do something like
GLCD.print(GLCDUTF8('Æ'));
Of course you can still send the actual character code value:
GLCD.print(0xc6); // print Æ
I can't re-define the write() function in openGLCD to take a 16 bit value instead of an 8 bit value
which would then allow either 8 bit or 16 bit characters so that you could do:
GLCD.write('Æ');
because the write() function is virtual and is declared as using a 8 bit value
in the Print class which comes with the IDE.
I could add a writeUTF8() function?
GLCD.writeUTF8('Æ');
All the solutions are pretty ugly.
I think that there are some gcc options to alter how extended character sets treat characters.
I'm guessing that those will also result in a mix bag in that while it may solve a few issues, it will
probably create others.
And then, there is still the issue of the interface in side Print as being unsigned 8 bit values
so you can't ever make it fully transparent and "just work" for all cases.
--- bill