In Flash Studio artists create text fields visually by drawing them on stage with a mouse and then entering the corresponding text. The font applied to a text field is selected by name out of the list of fonts installed on the artists system, with an embedding option available for content playback on systems that do not have the required fonts.

In addition to using font names directly, artists can also create font symbols in a library and then use them indirectly based on a symbol name. Combined with character embedding, font symbols create a powerful conceptual framework for portable and consistent game UI asset development. The rest of this section briefly goes over the basics of text field creation and character embedding. Developers are encouraged to refer to the Flash Studio documentation for a more detailed explanation.

The Flash font symbol system is convenient and easy to setup; however, it has a number of limitations that make it hard to use for sharing and substituting fonts for internationalization. The details of how these limitations are addressed in Scaleform will be presented in Part 1 – Creating the Game Font Library.

Artists create text fields in Flash by first selecting the Text Tool and then drawing the corresponding rectangular regions on stage. The various attributes of text, including the text field type, font, size and style are configured in the Text Field properties panel, commonly located at the bottom of Flash Studio. This panel is illustrated below.

Although the text field can have many options, the critical attributes for this discussion are circled above. The most important option for a text field is text type in the top-left corner, which can be set to one of the following values:

• Static Text
• Dynamic Text
• Input Text

For game development the Dynamic Text property is going to be the most commonly used field type, as it supports content modification through ActionScript, as well as font substitution and internationalization through the user-installed GFx::Translator class. Static text does not possess any of those features and thus closely resembles vector art in functionality. Input text can be used whenever an editable textbox is needed.

The other two fields circled above are font name, in the top line of the property sheet, and font rendering method. The font name can be selected to use (a) any one of the fonts installed on the developer’s system or (b) any one of the font symbol names created in the movies library. In the example above, “Arial” is selected for the font name. Also, the font style can be configured through the Bold and Italic toggle buttons.

For internationalization, the font rendering method is the most important setting, as it controls the character embedding in the SWF file. In Flash 8, it can be set to one of the following values:

• Use device fonts
• Bitmap text (no anti-alias)
• Anti-alias for animation
• Anti-alias for readability

If you select “Use device fonts”, a system-specific method of font rendering will be used, with font data taken from the operating system. One advantage of using device fonts is that the resulting SWF file will be small and use less system memory when played back. However, problems may occur if the target system does not have the requested font, in which case an alternative will be chosen by the Flash player. This alternative font may not look the same as the original and/or many not have all of the required glyphs. For instance, on a game console where there is no operating system font library, no text will be displayed. The unavailable glyphs will be rendered as squares in Scaleform.

Instead of using system fonts, the “Anti-alias for animation” and “Anti-alias for readability” settings rely on the embedded font characters, rendering them with animation performance and high quality optimizations, respectively. Whenever one of these options is selected, the Embed button becomes available, which allows users to select character ranges that will be embedded for the font.

In order for embedded font rendering to work, characters must be embedded for the specified font in at least one TextField in the file (if font is exported then no textfields are required). If the necessary characters are not embedded, device fonts will be used with all of the limitations described above (unless GFx::FontLib is relied on in Scaleform as described later on). To embed font characters, users need to press the Embed button that will show the Character Embedding dialog illustrated below.

In the embedding dialog, users can select the desired character ranges that will be embedded for the text fields currently selected font and style. All text fields that use the same font style will share the same embedded character set, thus it is usually enough to specify embedding for only one of the text fields.

Users should be aware that from the point of view of embedding, bold and italic attributes of the font are treated independently (see “Style” combobox on a screenshot above). As an example, if both plain Arial and Arial Bold styles are used, they must both be embedded separately, increasing the memory footprint of the file. Changing font size, however, can be done without increasing the file size or memory overhead. For more details on fonts and character embedding, please refer to the Using Fonts section in Flash Studio documentation.

Embedding characters is the only truly portable way to use fonts. When font characters are embedded their vector representation is saved into the SWF/GFX file and later loaded into memory on use. Since glyph data is a part of the file, it will always render correctly, independently of the fonts installed on the system in use. In Scaleform, embedded fonts will work equally well on game consoles (such as Xbox 360 or PS4) and desktop PCs (such as Windows, Mac, Linux). The unavoidable side effect of the embedded font use is the increased file size and memory use. Since the size increase can be significant, in particular for Asian languages, developers will need to plan game font use ahead of time and share fonts whenever possible.

In order to understand the kind of memory effect character embedding has in Scaleform, consider the following table that outlines memory used as the number of embedded characters increases.

Embed Character Count	Uncompressed SWF Size	Scaleform Runtime Size
1 Character	1 KB	450 K
114 Chars – Latin + Punctuation	12 KB	480 K
596 Chars – Latin and Cyrillic	70 KB	630 K
7,583 Chars – Latin and Japanese	2,089 KB	3,500 K
18,437 Chars – Latin and Traditional Chinese	5,131 KB	8,000 K

The sample table was created for Scaleform 2.1 by embedding the “Arial Unicode MS” font. As outlined above, including European character sets is relatively inexpensive, with developers being able to include 500 characters for roughly 150K memory use increase. This is enough for several different font styles in localized distributions. With Asian languages, however, the amount of memory used becomes much greater due to the large number of glyphs involved.

Since embedding large character sets can consume several megabytes of memory, developers will need to plan their font use ahead of time to reduce the amount of memory used. There are several techniques that can be used to keep font memory under control:

1. Limit fonts and font styles used to a pre-determined set before UI art assets are developed. Bold and italic font styles are embedded as separate character sets in Flash, so you should treat them as entire separate fonts and use them only when necessary. Different font sizes, however, incur no additional overhead, so they can be used without causing memory increase. In the future, we will provide a fake bold and italic option that avoids requiring additional font characters to be stored for bold and italic versions.
2. Share fonts across files by either using GFx::FontLib and/or importing. Embedding the same characters in every single file may cause unreasonable increase in asset size, memory use (if the later files are simultaneously loaded) and load time. When possible, it is best to store embedded fonts into separate SWF/GFX files which are shared and thus do not need to be duplicated in memory or reloaded. The use of GFx::FontLib will be discussed later in this document.
3. Only embed the used characters for Asian character sets. In Asian localized games it is possible to avoid embedding all characters in the language and instead embed only those characters that are used in the game text. After translation, all of the game strings can be scanned to generate the required unique character set, which is then embedded. As long as the game does not require arbitrary dynamic text input through IME, limiting the character set will result in significant space savings.
4. Consider using GFxEport font compession (-fc option). Generally 10%-30% size reduction can be achieved without noticeable reduction in quality (see Using font compacter - gfxexport in Part 4: Configuring Font Rendering).

For a best looking internationalized game, users may choose to combine all of these techniques, limiting the fonts used and sharing them through GFx::FontLib. For Asian languages, embedding only the characters used or if IME is required, embedding only one complete font, would result in substantial memory savings.