Replies: 5 comments 8 replies
-
Nothing to add at this point, except an exuberant THANK YOU for the effort you guys have clearly put in to this advancement already. I've gone to great lengths to get colored emoji working in my project and it's a hack at best while still only being a half measure. I'd abandon it all in a heartbeat if this goes anywhere. edit: I am still curious, however, as to how MacOS and the old Pepper FlashPlayer in Chrome (PC) rendered colored emoji without any extra effort from us. Like, what sorcery were they tapping in to that made it just work? |
Beta Was this translation helpful? Give feedback.
-
Since text input/output is a core and most common feature in most apps/games, any advancement effort is most welcome. Personally, I don't have a need for emojis in my current projects, but I'm happy to see that this feature and text engine in general get its turn. What are the plans when could dynamically load font from bytearray you mentioned be realized and will there be support for subsetted and obfuscated fonts (#1448)? |
Beta Was this translation helpful? Give feedback.
-
Really happy to hear you guys are looking into this. I'm using Starling/Feathers and have had pretty big problems both with colored emojis and sometimes when displaying characters in (some incorrect Chinese characters, limited RTL language support, for some reason I couldn't bold characters in some language on iOS with a device font or something like that) |
Beta Was this translation helpful? Give feedback.
-
@ajwfrost |
Beta Was this translation helpful? Give feedback.
-
We got names like "𝓐𝓵𝓮𝔁𝔂𝓪💗" and somehow it passed trough the app successfully. We had some combinations that failed when rendered in a Feathers UI String concatenation is slow. Recently I've concluded it's faster to write Strings to a |
Beta Was this translation helpful? Give feedback.
-
Hi
We've been looking at the text output options in AIR, and how the various different options work across platforms - with a particular focus on how to achieve new(ish) things like support for coloured emoji characters.
There are a lot of different ways of doing text, so trying to put some information down here, and see what people's experiences are and what new requirements there might be....
One quick note before we dive into the text display: some information about the
String
class itself. This is implemented in a similar way to the JavaScript string class, which means it should be UTF-16. In fact there seems to be a lot of assumption in the code that it's UCS-2 i.e. two-byte characters; support for code points above 0xFFFF was added later but only partly. So, if you (up to 51.0.0.3) callString.fromCharCode(value)
, thenvalue
will be truncated to 16 bits. There is handling with the textblock related code (Flash Text Engine) to deal with surrogate pairs i.e. the UTF-16 encoding of a Unicode code point higher than 0xFFFF, and we've now correctedString.fromCharCode
so that if you call it with a higher value - like emoji 0x1F600 - it will return a string that contains two character codes, which together represent that emoji.So, be aware that if you're dealing with some high code point values, the string length will give you the number of UTF-16 entries, but conceptually that may not equal the number of characters you'll see when displayed. In fact, it's possible to have e.g. 5 UTF-16 entries which should be displayed only as a single character, if you look at modifiers..
Also fyi the
String
class does have optimisations for when it deals only with ascii characters, and it should properly handle UTF-8 input as well e.g. when reading from byte arrays (or IDataInput) etc.So: fundamentally, there are three different ways to display text:
StageText
we can cover easily: on desktop platforms this just uses a normalTextField
object; on Android/iOS it uses the native text display/input classes, rendered as an overlay layer above the AIR stage. It only supports device fonts i.e. you give it a font name and it tries to get that font from the OS, as if you were creating a native mobile application... But, because of how this works, it means that you can pass in an emoji character code and the OS will display this using its internal fallback mechanism, resulting in a properly colourful emoji.For the other two mechanisms, they are quite different, but they both have two different ways to pick up the required font information:
Device fonts
Device fonts are identified by the name, and then if those are available on the device, they are used for rendering the text. We use operating-specific mechanisms for rendering the strings, so how the fonts (and emoji characters) appear is dependent on that. So for example, on Windows we use (currently) GDI "TextOut" type methods, and these can display emojis but only in black and white. We're looking to switch to Direct2D text output, which should then support the coloured emojis.
If you specify a font such as "Arial", and then your string has an emoji character, then the font will need to use a "fallback" mechanism to find the glyph to use in displaying this character. That seems to work with TextField (?) .. although on iOS it seems that the mechanism we use for text output just doesn't support any emojis (which are bitmap-based characters, rather than outline-based). With FTE, there are a set of fallback fonts that are specified within the AIR build/configuration, based on the character categories. Currently (up to 51.0.0.3) there was no category for the emoticon range so we are adding this, using the font names that appear to be the appropriate default values for each operating system. This means that emojis should start to appear if using device text in FTE/TextBlock .. but with the earlier caveats about the OS-specific rendering. It would equally have been possible to support these by creating a
FontDescription
using the OS-specific font names such as "Segoe UI Emoji" etc.One other difference between the traditional TextField and the FTE methods is where FTE handles advanced layout, glyph combinations, right-to-left, etc .. whereas the TextField text display just throws the string at the operating system.
Embedded fonts
Embedded fonts are where the font definitions are built into a SWF file. There are two main variants of how a font definition is embedded:
To embed the font, you can use Animate or you can use an embed directive with the ActionScript compiler, e.g.:
This should result in the DefineFontX tags being added to your SWF file. Note that there can sometimes be issues with font embedding, where the TTF file could contain things not supported by the conversion tool, so if you see a null reference error or problem with "addFrame" in your compiler output, check whether it helps to switch out the TTF file with a basic one..
For embedded fonts, there are currently no fallback mechanisms. So if you want to draw an emoji character, you need to select the right font for that. This does mean that it should always be possible for you to display text that contains emojis, on all platforms, but you need to do that manually i.e. detect if the text has any emojis, and if so, switch to an appropriate font that contains the emoji glyphs.
In terms of colour .. these all store the font definitions as outlines, they do not have any support for bitmap font characters which are used by emojis. You can see something similar in Microsoft Word if you try to do an "Insert symbol" and select the Segoe UI Emoji font: the emojis look black and white in the symbol picker because that uses their outlines; but once you insert the character, it renders with the bitmap and shows up in colour.
So to support coloured emojis properly, using embedded fonts, we need two things:
Currently we are looking just at the Flash Text Engine for this, because things like fallback mechanisms and glyph combinations (e.g. where you combine a 'flag' emoji with a 'rainbow' emoji to result in a single 'rainbow flag' character) are already dealt with in the underlying code. So then, we "just" need to add support for the bitmap and colour bitmap OpenType font tables... and of course, we also need a way for people to be able to specify the fallback font to be used in case a glyph isn't found in the primary one.
One restriction though: we currently don't have a way to update how the ActionScript compiler processes TTF files and embeds the data into the SWF. We are seeing whether it's possible to get hold of this, but as a workaround we will have a way to dynamically load a
FontDescription
from some bytearray data; this could either then be loaded in at runtime, or embedded in the SWF as a binary data field.Will keep people updated here with details of progress and implementation mechanisms/examples. And we'd be interested in feedback/comments of course!
thanks
Beta Was this translation helpful? Give feedback.
All reactions