I have an embedded font with a unicode range targeted to the latin base set:
unicodeRange = 'U+0020-U+00FF'
When my string includes arabic on a mac or kanji/han (chinese) on windows, the failover fails, as in I get the rectangles instead of a replaced device glyph.
It was my understanding that the FTE in player 10 swapped out failed glyphs for device glyphs per character. This appears to be working, but not for all cases.
On my mac, chinese device glyphs get inserted just fine in the case of this string: "車 and あります Kanji Test"
On windows this string fails by placing the rectangles in place of the chinese characters.
Another example shows arabic on a mac with the rectangles instead of device arabic glyphs: "Arabic Test كيبورد للكتابة بال"
Thanks in advance for any insight.
Using player 10,0,32,18 on a mac and 10.0.42.34 on windows.
Using TLF version 188.8.131.5285
When you embed the font for Arabic, are you including the Arabic glyph set?
The glyph fallback has improved with the latest Player, you could try the beta version of 10.1 and see if it helps. You can download it from here: http://labs.adobe.com/technologies/flashplayer10/. On the Mac, I know that some fonts do not have the approrpiate OpenType tables. Can you tell me what font you are using for the text?
Are you using the Flex compiler to embed the font, or something else?
These details will help us to figure out what is going wrong.
I am not including the Arabic glyph set, just the basic latin character set. So any font I use (using a MyriadPro font) would fail on Arabic, Chinese, anything other than latin characters. I am using the flex compiler and embedding cff fonts, which is working well.
So the goal here is to embed a limited set of glyphs (size reasons, of course) but have the text engine deal with any out of range glyphs automatically. I have previously set up the whole song and dance in player 9 to deal with glyph failure, but I am hoping not to have to replicate that in player 10.
This is an intriguing scenario. Some device fonts work for Arabic (Arial, Times New Roman), some don't (Verdana, Myriad Pro). This is when I set the FontLookup to device (FontLookup.DEVICE). None of those fonts if I am not mistaken have Arabic or Chinese glyphs, so the fact that Chinese is successfully replaced but Arabic is not (rectangles) is the disturbing issue.
I have also added some fonts to the fontFamily property, comma-delimited, as fall back options, such as "Verdana, Arial, _sans" but that doesn't work with my strings. I have a hunch after re-reading the fontFamily docs that those fallbacks only work if a font is not found, not as a per glyph replacement strategy.
I believe the rectangles you're seeing with Arabic and device fonts was a known issue that got fixed in Player 10.1. Which made me recall that there were a lot of glyph fallback fixes that were made after the Player versions you're using. You may want to see if the embedded issues you're seeing still happen in the most recent Player 10.1 beta.
And you're right - the font list only works to determine what font gets applied to all of the text. If there are glyphs missing the Player looks up it's own list of fonts to use to display those glyphs.
Funny. I just finishing a player upgrade to 10.1.x when I saw your post. Just did some testing on the Mac side for Arabic and both embedded and device scenarios now show a properly replaced Arabic. Now to test Windows, but it looks like 10.1 may be just what the doctor ordered.
The Windows (FF, IE) test with the Beta 2 Pre Release of FP 10.1 now shows the Chinese characters that were rectangles in the 10.0.x releases. Looks indeed that some very nice core fixes around text were made in 10.1.
Europe, Middle East and Africa