the confusion comes from the cleverness of the design of UTF-8, by making the first 128 bytes have the identical encoding to ASCII most software just works when it encounters UTF-8 data, so long as all they encounter are those characters.

The facts are that UTF-8 is a variable length encoding, and can encode any Unicode character. UTF-8 is the encoding of choice in modern software as there are no byte-order issues and it is extremely compact for western characters.

Many legacy systems have given their own names to their level of Unicode support, but that does not change the standards. Some major systems pretend to support it and still do not do it properly.

It appears that AKG does nothing special, consuming rendering UTF-8 data as it if was ASCII

There are software libraries such as ICU which are freely available and used by all major operating systems under the covers to provide correct Unicode support, including reliable conversion from UTF encodings to other code pages and encodings as well as different collations (sort order) for different cultures and upper and lower casing rules which vary by culture, support for right -to left scripts, etc.

Yeah, defo need to use that command I mentioned with variable length format for grid image as detailed by the help files then. Also having posted without said link was pretty dumb of me lol, it's likely useless but have edited post anyway.

mb 3/4 so perhaps UTF-8 on its own negates the rest? This is what I think Phaelax is eluding to? ie when talking about it to account for software that does not fully implement all 4 bytes versus a fully supported software that auto decodes it all. Essentially, in a case where UTF-8 is not implemented beyond 1 byte, it does not force a name change from UTF-8 therefore the term is not directly tied to exclusivity. If any of this is true you are both right, but what Phaelax states is more accurate where AppGameKit is concerned, which is not the exact reason as such but implies there has been no need so far to flesh out implementation to support mb 2, 3 & 4?

I had the impression that when something says UTF-8 and doesn't specify mb 2/3/4 then I always took that as supporting only 1 byte encoding. I know when setting up tables in SQL there is explicit encoding options for mb3 or mb4. But then again, I suppose its plausible that UT8-mb4 is so common now that simply stating utf8 could imply the full range. Anyway, that's where my thought process on the matter came from.

AGK has support for 4 byte UTF-8, in fact all strings are recommended to UTF-8 from now on and the old Windows-1252 encoding is deprecated.

AGK will convert any UTF-8 encoding into its unicode value and then ask the FreeType library to draw that unicode value from the given TTF file. The chr() function takes the unicode value directly as an integer. For example chr(128513) should be a smily face (unicode 0x1F601)

So AppGameKit should support anything that FreeType and the TTF font file can do. I think we are using FreeType 2.7.0