Open ylazy opened 1 month 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...
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.0U+0000-10FFFF
.\u{nnnnnn}
for example"\u{1F4A9}"
= 💩. Ref.String.codePointAt()
. Ref.TextField
andFTE
(Flash Text Engine)Really needed for modern applications.
Thanks!