I have had a number of emails, messenger texts, and commentâ€™s on my blog, asking for further information from my presentation notes on localizing flash. Localizing flash has such a wide scope of information, when I prepared my presentation I did take the â€˜data blastâ€™ approach of delivery.
I had a good idea the area(s) that people might like more in depth information, but I also wanted to take into account some broader work flow and process issues that I feel really need to be discussed. In this post I would like to present some more detailed information regarding one of the slides I used at the LFPUG presentation that, as expected, has generated a lot of feed back.
Managing Text & Fonts
During the presentation I had split this key area of localizing flash content into two sub-headings, each sub-heading had a number of points I wanted to cover.
Part 1 – Fonts
- Understanding character sets, character maps & glyphs tables.
- Using embedded fonts and or non-embedded fonts.
- Flash 8 and advanced anti-aliasing.
- File size implications of fonts in flash.
Part 2 – Construction & Style
- Using font symbols.
- Using dynamic text fields.
- Shared fonts, font libraries and font symbols.
- The TextFormatObject & CSS.
Understanding Character sets, character mapping and glyph tables
Before getting into the nitty gritty of the practical side of how you go about managing the text based content in a localized flash project, I want to cover off the underlying concepts and processes that support it. Hopefully my terminology will be correct enough for the purpose of this article, feel free to leave comments correcting me where appropriate.
When trying to localize text based content in flash you will need to understand a little regarding Unicode, and how the fonts and applications you are using support it. So what is Unicode.
Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language
In addition to this Unicode characters are grouped into character sets. Within flash these can be found in the embed fonts options of the text field properties inspector.
As flash developers we should be able publish content to pretty much any language on the planet. “we should be able”. What often upsets this localization utopia is that many, many times we will find that the fonts provided, or requested within a project don’t completely support Unicode. If this is the case it will result in a number of display issues within your flash production, including missing characters, or often a “?” or a square symbol, being displayed instead. Another, slightly less common problem can be a poorly constructed font that has characters incorrectly mapped. This would result, for example, in the glyph for “A” being returned and displayed as “B”.
In actual fact there are few font faces that do fully support the whole Unicode table, and generally they are the standard system font faces for “sans”, “serif”, and “monospace” display, (Arial, Times, Courier on Windows). In part this is because to implement a complete Unicode font would be a time consuming and costly, production. There are around 65,000 (I think?) individual Unicode character codes to support, meaning over 65,000 characters to produce and test for some poor font maker.
With this in mind it is always worth checking the level of Unicode support that the fonts you are being asked to use support, you will save yourself a lot of tears as your project progresses.
Having assessed the support that your fonts offer for Unicode you need to find an acceptable level of Font Embedding. I have found this to be very similar in approach to deciding the compression that is applied to an image for the web. There is always going to be a trade off between the number of fonts you embed, and the final file size of a project. For example as a test, and to refresh my memory, I did an export of a flash movie that simply had a Dynamic text Field supporting Arial MS Unicode and embedding all character sets. The resultant SWF was 9.7MB uncompressed (7.8MB compressed).
The reason for large file size is that when flash embeds fonts for use in the player they are essentially converted to vector shapes that are embedded in your movie. When you get to some of the more exotic languages (Asian and Right to Left Languages for example) the individual glyphs are very elaborate, these results in some complex vectors, and thus larger file sizes. In addition the shear number of characters is HUGE, a number of languages have many more individual characters than us Europeans, the basic Korean character set has 3454 glyphs!
As of flash 8 the use of embedded fonts becomes less of an issue, with respect to visually acceptable text rendering. Making use of the advanced anti-aliasing options we are able to yield far better readability than is possible even with embedded font glyphs. However there are still some issues related to these options when trying to animate and scale text that is displayed using them. So depending on the design and visual treatment you are dealing with you will need to keep this in mind.
In my next post I will look at how to manage fonts within your files, it will roughly follow the structure of the ‘part 2’ heading above apply some of the code examples from my brief previous post.
References from this Article
Unicode.org, an invaluable source of information regarding UTF and Unicode
Online Unicode look up table
Information on Flash 8 text rendering issue in Saffron
Further information on Flash 8 text rendering issue in Saffron
LFPUG Presentation Running Notes