Skip to main content
Participant
December 22, 2009
Answered

Glyph failover not working with FontLookup as both embedded or device?

  • December 22, 2009
  • 2 replies
  • 1944 views

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.

NOTE:

Using player 10,0,32,18 on a mac and 10.0.42.34 on windows.

Using TLF version 4.0.0.10485

This topic has been closed for replies.
Correct answer

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.

2 replies

Participant
June 10, 2011

(I've moved my question to a separate discussion: http://forums.adobe.com/thread/863551) - thanks

Adobe Employee
December 23, 2009

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.

Thanks,

- robin

December 23, 2009

Another question: If you choose a device font for the text (that does not contain the glyphs) do the glyphs show up, or do you get boxes in that case as well?

Participant
December 23, 2009

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.