views:

1023

answers:

1

Greetings,

I'm in the middle of writing a Flash application which has multilingual support. My initial choice of font for this was Tahoma, for its Unicode support. The client prefers a non-standard font such as Lucida Handwriting. Lucida Handwriting doesn't have the same, say, Cyrillic support as Tahoma, which poses a problem that there are a few ways to solve, and I'd like to ask for your advice on which is preferable:

From what I understand, I could:

  • Give the client a list of fully Unicode-compatible (Cyrillic, Hebrew, Arabic, Traditional Chinese, East Asian, etc) fonts to choose from. (I have no idea where to get such a list; my search of the web has resulted only in lists of partially unicode-compliant fonts. Try http://look.fo/list-of-unicode-compliant-fonts as a good starting point to see where I looked).
  • Depending on the client's location (which we already have), render in Lucida Handwriting for English-speaking users and in Tahoma for international users. This may be somewhat of a headache; has anyone had any experience with this approach?
  • Build a new font (IE, AlexeyMK Bold) which uses Lucida Handwriting for English and Tahoma for everything else. This ads something like 500k to the weight of the Flash file, but should (if I understand correctly) only be loaded the first time.

What do you advise? Which of these are reasonable solutions, and which are completely out there? Is there a way that I'm not thinking of?

Much thanks! Alexey

EDIT: A good article on the subject: http://www.itworld.com/print/58558

+2  A: 

Well, ultimately you have only two real choices: either you embed a font in your SWF, guaranteeing what your fonts will look like, or you don't, and use device fonts. (Or a mixture of the two, using embedded or device fonts depending on region.)

If you don't embed any fonts, then whatever font you define for your text is ultimately just a suggestion - what the user will see is device fonts, being rendered by their own machine (using the fonts on that machine). So you can "suggest" Tahoma, but what the user sees will depend on whether they have that font (and it might vary for, say, Mac versions of the font vs. PC versions). Naturally this also depends on support; if they don't have Asian fonts then then they won't see any Chinese for example. (Note: you can also choose a font like "_sans", which just tells the client to use its standard sans-serif font. My guess is that in practice this will wind up being the same font that would have been chosen if you'd defined "Tahoma", but YMMV.)

If you embed your fonts, then the user will see exactly what you expect them to, because the font is rendered by Flash and not the OS. But if you embed fully for all regions, including the glyphs needed for Chinese, then I think you'll find it adds considerably more than 500K.. more like 2-5MB in my experience. But maybe there are some details I'm missing. Anyway, for content to be delivered over the web I would generally assume that, at minimum, asian fonts should be device fonts.

To add a word about a mixed solution, I've done this and it's doable. That is, assuming you can add the logic to your SWF, you could (for example) make two of each text field, one using embedded "Lucida whatever" and the other using non-embedded "_sans", and then at runtime make one of them invisible and put text in the other, depending on which region you're showing. (I did this by making a single LocalizedTextfield component, and having it read the locale out of a static property when it initialized.) Then you simply have to decide, for each locale, whether the file size is worth the display for that particular set of glyphs.

The final word is, you can't necessarily assume that the file size incurred by your fonts will only be loaded once. If you make your content the straightforward way and embed fonts in your text fields, then the font info will be part of your SWF, and thus loaded every time no matter what. To externalize it you could make the Label component a separate file, and then the decision to load it or not is up to the browser's caching settings. You can also externalize the font resource itself and use it as a shared resource, but in AS2 this is somewhat hairy to get working. I've heard it's easier in AS3 but not done it myself.

fenomas
Much appreciated!
AlexeyMK