search

airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
206 stars 11 forks source link

Unicode updating & Emoji displaying #3364

Open ylazy opened 4 months ago

ylazy commented 4 months ago

Hi!

We've been stucking in U+0000-FFFF for a long time (Unicode 1.1 was released June 1993). And now it's Unicode 16.0 U+0000-10FFFF.

Really needed for modern applications.

Thanks!

ajwfrost commented 4 months ago

Hi

We can look to add \u{nnnnnn} into the compiler, that should be a fairly self-contained update.

We already support String.fromCharCode() with any unicode value (see release notes of 50.2.4.5) but we can add a new API to implement that String.codePointAt() method in AIR 52. Interesting that if you have a character that needs two UCS-16 values - such as your 0x01F4A9 character - then if you call codePointAt with the index of the first UCS-16 values, you get the full unicode value back, but if you call it with the second, you just get the value of that second part of the surrogate pair. So codePointAt is only different from charCodeAt if you hit an index that contains the first value of a surrogate pair..

Emoji output has been improved within the FTE/TextLine classes, in AIR 51.0, so it should be fairly consistent there. For TextField it's a little platform-dependent, and also dependent upon the fonts and mechanisms used. TextField doesn't have the same complexities in terms of the font fallback support that's needed for displaying emoji characters, so it's really not suitable for advanced things like combining of glyphs (for script languages), doesn't handle RTL text, etc. On a mobile device you're perhaps better off using StageText. I know there are some other limitations when using TextField e.g. on Windows the GDI font rendering doesn't support coloured glyphs, so we had been looking at supporting a different mechanism for fonts, but that could mean losing support for older Windows versions..

I'll see if we can put together a compatibility table to show what can be done in each type of text field based on mode, font, operating system etc...