Flash Font Embedding Using MXMLC Compilation - Specialmoves

Flash Font Embedding
Using MXMLC Compilation

Specialmoves Labs

Written by Matt Bilson,

Ever since the early days of Flash, embedding fonts and supporting both multiple and large characters sets has been somewhat of a sticking point. Whilst support for various intricacies of font loading and embedding has gradually improved with each version, there are some inherent difficulties.

One big difficulty is handling the embedding of large character sets such as Japanese and Chinese. This post will present the fully automated font embedding solution we used for a 500 page site available in eleven languages (including Traditional Chinese and Japanese) which is regularly updated by users of a bespoke CMS.

The problem

Generally, a Flash site in English will need to embed the characters a to z (upper and lowercase), 0 to 9 and punctuation. A SWF containing just these characters in Arial comes in at 12kb. Supporting other Western European languages, such as French, Spanish and Italian requires adding only a handful more accented characters. The problem comes when building a Flash site in languages such as Traditional Chinese and Japanese which have much larger character sets.

As you can see from the table below, if you were to embed all the characters, the user would have to wait a substantial amount of time before they can see any text on your site.

There are numerous approaches to this problem, which include…

  • Using a font of your choice for languages with small character sets, and defaulting to a system font (_sans or _serif in Flash) for languages with large character sets. However this means that styled, designed and intricately laid out typography is sacrificed in the name of convenience. Also, it’s not possible to adjust the alpha or rotation properties of text in a system font, so this approach limits animations and transitions that can be applied to the text without a work around such as converting it to a bitmap.
  • Manually telling Flash which characters to embed. However, if the copy in the site is likely to change, this approach will make deploying changes painful and impossible to automate.
  • Create a custom font which contains just the characters used in the site, and embed the whole custom font in the site. However, similarly to above, if the copy in the site is likely to change, deploying an update becomes a laborious, manual process involving font editing software.

A quick Google search reveals many other approaches and whilst at the end of the day it depends on the nature of the site being created, here is the approach we took.

Our approach – automated, server-side, command line embedding

This approach was developed to meet the following requirements :

  • The site should display text in custom fonts wherever possible.
  • The font file downloaded by the user should be as small as possible – no superfluous characters increasing loading times.
  • There should be no manual aspect to the process – as developers, we shouldn’t need to be involved in the deployment process, this is something the client can do themselves using our bespoke CMS. The font handling system should also be invisible to the CMS user. When previewing and deploying updates, they should instantly see new characters in the custom font. As Steve would say, “It just works”.

The process currently runs on .NET 3.5 on an IIS 7.5 server, and goes like this…

  1. A .NET application, running as a scheduled task, polls the database for changes made by a user of the CMS. N.B. For other sites, the script could just as easily check for changes in XML or JSON files.
  2. Upon finding a change, the .NET application takes all the user-facing text from the database for the version of the site being updated (i.e. if the content of the site being updated is a Chinese page, only the Chinese font is updated.)
  3. It then parses this text to remove duplicate characters, leaving a comprehensive list of all the characters which could be displayed to a user viewing the site in this language.
  4. Next, it converts this to a list of comma separated unicode values which represent the characters.
  5. The application then inserts this comma separated list of unique unicode values into a template ActionScript file which is used as the document class for the font library SWF. There are different ActionScript templates for each version (language) of the site, due to different fonts being used in each. Here’s an example of the Japanese file:
package com.example {
	import flash.display.MovieClip;
	import flash.text.Font;
 
	public class [[CLASSNAME]] extends MovieClip {
 
		[Embed(source="../../fonts/A-OTF-FutoGoB101Pro-Bold.otf", fontName = "HeadingFont", fontWeight="bold", mimeType = "application/x-font", unicodeRange = "[[CHARLIST]]" )]
		public var headingFont:Class;
		[Embed(source="../../fonts/A-OTF-GothicBBBPro-Medium.otf", fontName = "BodyFont", mimeType = "application/x-font", unicodeRange = "[[CHARLIST]]" )]
		public var bodyFont:Class;
		[Embed(source="../../fonts/A-OTF-MidashiGoPro-MB31.otf", fontName = "MinorFont", mimeType = "application/x-font", unicodeRange = "[[CHARLIST]]" )]
		public var minorFont:Class;
 
		public function [[CLASSNAME]]() {
			Font.registerFont(headingFont);
			Font.registerFont(bodyFont);
			Font.registerFont(minorFont);
		}
	}
}

The application searches the file for double square brackets, and replaces these with the necessary values for this class; [[CLASSNAME]] is replaced with the language, and [[CHARLIST]] is replaced with the list of unicode values.

The template ActionScript files use Embed meta-tags to embed the font into this SWF at compile time. The parameters of the meta tag can restrict the characters being embedded to just those needed – the list of Unicode values representing every character needed in the site – rather than the whole font.

Also in the meta-tag, each font is given a fontName – HeadingFont, BodyFont or MinorFont – depending on where they will be used in the site. This name is how the font is referred to by CSS or TextFormat objects within Flash. Each language version of the site uses slightly differing fonts to ensure good readability and complete character set coverage. Using the fontName attribute ensures that the code of the site can use this generic name, rather than using the specific name of the font, which will change depending on which language the site is being viewed in.

When run, the constructor of the class registers the font with the global Font object, ensuring that the embedded glyphs will be available to any site SWF which loads in this font library SWF.

The application then uses command line compilation (mxmlc) to compile this class into a SWF. Here’s an example mxmlc command :

mxmlc -o {rootDir}\Webroot\fonts\{lang}.swf
-sp {rootDir}\FontGenerator\src\com\example\
-library-path {flexSDKDir}\frameworks\locale\en_US
-library-path {flexSDKDir}\frameworks\libs\player\10\playerglobal.swc
-library-path {flexSDKDir}\frameworks\libs\flex.swc
-library-path {flexSDKDir}\frameworks\libs\framework.swc
-library-path {flexSDKDir}\frameworks\libs\rpc.swc
-library-path {flexSDKDir}\frameworks\libs\utilities.swc
-managers=flash.fonts.AFEFontManager
-default-size 550 400
-default-frame-rate 31
-default-background-color 0xFFFFFF
-target-player=10
-debug=false
-- {rootDir}\FontGenerator\src\com\example\{lang}.as
  1. Finally, the application uploads the SWF into the appropriate location on the server and increments a font file version number property.
  2. The code which loads this SWF into the site appends this version number to the SWF’s url as part of a query string – e.g. “fonts/japanese.swf?fv=15″. This ensures the SWF is cached by the user’s browser between visits, until it is superseded by a new version.

Advantages of this approach

The main advantage of this approach is the file size; only necessary characters are embedded, keeping file size as low as possible. The Japanese font file used was 1.6Mb, this contains 3 fonts, and if the whole Japanese character set was embedded in each font, the file size would be 9.8mb.Secondly, the process is entirely automated. Triggered by a CMS user’s actions, .NET compiles and deploys the font file. It involves no human interaction. As well as reducing the time it takes to update and deploy the site, this also reduces the opportunity for human error.

Disadvantages

One disadvantage is that the font compilation system needs to know the characters which need to be displayed in the site before it can compile them into a SWF.

This means that for input fields, we use a system font. This is an extremely minor issue due to the rare use of input fields in this site, and due to the nature of system fonts, it also ensures that input fields are as clear and readable as possible.

The future

One improvement we’re working on is to only embed characters in the fonts they will be shown in. For example, if the character ‘Z’ is only used in headings in a site, why embed it in the body font? Hopefully knowledge of this approach will help others in creating similar sites in the future. If you have a unique approach to font embedding, have worked on a site that would benefit from this system, or have any tips, thoughts or recommendations, then let us know.