Flex font embedding with Spark and Halo made easy!

I’m going to keep this one really brief. There is so much stuff written about fonts and Flex on the Web that the subject seems incredibly complex. It is not(!) and I’m going to quickly outline what I think is the best real-world production approach to take with fonts when using Flash Builder 4.

Firstly, understand that you often *should* use embedded fonts inside your complex Flex projects. The reason is simple: you probably don’t your text to look slightly different depending on what computer it’s running on. For example, a Windows machine and Mac will have different versions of the Arial font. Unless you embed the font your are going to use, you do not know exactly what the font will look like to the user, and the differences can be very significant from the design perspective. Better to embed fonts, so it always looks the same.

So, you need to embed fonts. How do you do this? The most convenient way is to use a style declaration in the root of your project e.g.

       
<fx:Style>
        @font-face {
            font-family: "MyriadPro";
            src: url("assets/MyriadPro-Regular.otf");
            embedAsCFF: true;
	}
</fx:Style>

Notice that we embed as CFF, which provides benefits such as advanced anti-aliasing. But, you howl, Halo (the stuff starting with mx) doesn’t support this! Don’t worry, this is covered in a moment.

Before moving on, we’ll optimize this some by only embedding the characters from the font we are likely to use, which keeps file size down.

<fx:Style>
        @font-face {
            font-family: "MyriadPro";
            src: url("assets/MyriadPro-Regular.otf");
            embedAsCFF: true;
            unicode-range: U+0020-U+007D;
	}
</fx:Style>

So now everything looks the same on each system, perhaps we have been able to use an exotic font, and we haven’t blown our SWF file size up too much. But there’s a problem, Halo’s mx controls show blank spaces where text should be.

No worries, this is simple too. You just need to override the class of the text renderer object used by the Halo controls.

<fx:Style>
        @namespace mx "library://ns.adobe.com/flex/mx";
        @font-face {
            font-family: "MyriadPro";
            src: url("assets/MyriadPro-Regular.otf");
            embedAsCFF: true;
            unicode-range=U+0020-U+007D;
	}
        mx|Alert, mx|Button, mx|Form, mx|FormHeading, mx|FormItem, mx|FormItemLabel {
            font-family: MyriadPro;
            textFieldClass: ClassReference("mx.core.UIFTETextField");
	}
</fx:Style>

Nice! There you have your production font strategy. Of course, the more of those sorry old mx controls you are using, the longer your list of mx|,… will be 🙂

Update: Google Chrome browser fonts problem on Mac OS X

You may have seen my earlier post on this topic here and thought “Yippeee” problem solved!

Well that’s true, if you’re on Mac and your font manager serves one of the standard Web fonts like Arial, then by removing the font from the manager and allowing Chrome to fall through to the version in the system font library you fix the problem (remember that the Chrome security model currently only allows it to read fonts from the standard systems fonts folder).

Unfortunately this does not work for all cases!! For example, if a Web page uses a font like Calibri, such as http://perspectives.mvdirona.com/2009/02/07/FacebookCassandraArchitectureAndDesign.aspx then this font won’t be in your system fonts folder. On the other hand, as in my case, it may be in your font manager.

You can’t delete it from your font manager, because there is no system equivalent

Currently, no obvious fix! // except… I decided Calibri wasn’t that important and disabled it 🙂 anyway

Come on Google sort out the Mac!

Google Chrome browser fonts problem on Mac OS X

Just about everyone in the Web/tech industry now has worked out that Chrome rocks. It rocks so much, that once you use it for a while, any other browser becomes unbearable (I won’t go into the design decisions that make it so much better, but please take it on trust and try using this browser for a while, searching via the address bar, adding extensions etc, if you are not already).

That is, except for some people on Mac OS X, because in some configurations Chrome screws up the display of certain fonts. When this happens, text in the fonts in question are represented by a series of A’s.

Cause: You have a font manager installed, such as Suitcase Fusion, which maintains fonts outside of the Mac OS X fonts folder. If the manager activates a Web font that is also a “system” font, such as Arial or Tahoma, when Chrome Beta requests the font from the system it will be directed to the managed copy. Unfortunately however, Chrome’s security model does not allow it to access and load font files outside of the system fonts folder.

Fix: Carefully go through the fonts in your font manager. Deactivate any copies of Web fonts such as Arial, Tahoma and Georgia (these fonts should already exist in your system fonts anyway). Restart Chrome.