Flex 3/4 Font Embedding: CFF-DefineFont4 vs DefineFont3

There are now two types of font embedding available to both Flash (CS4) and Flex 3 and 4. These are DefineFont3 (classic), and DefineFont4 (supporting CFF and the new text engine.)

In Flash, Flex 2 and 3 you’d traditionally embed fonts for use in the…

There are now two types of font embedding available to both Flash (CS4) and Flex 3 and 4. These are DefineFont3 (classic), and DefineFont4 (supporting CFF and the new text engine.)

In Flash, Flex 2 and 3 you’d traditionally embed fonts for use in the TextField class, whether that’s a vanilla TextField, or a component that uses the TextField class and has been set to use embedded fonts. This is DefineFont3 embedding. The steps are usually:

  1. Embed fonts in a SWF using the Flash IDE or the [Embed()] tag in Flex.
  2. Set myTextField.embedFonts = true; (or setStyle(“embedFonts”,true) for a component.)
  3. Either set myTextField.defaultTextFormat, use setTextFormat(), or setStyle().
  4. Set the text with .text or .htmlText (using CSS or the font tag).

With the new flash.text.engine.* package (available as part of the Text Layout Framework for Flex 3 or as standard in Flex 4), we have another way to do text that’s a lot more powerful than the old TextField. But it’s no direct replacement just yet (there are performance reasons), and at least for now you’ll probably be using them alongside eachother, particularly if your Flex project is using the Halo (Flex 3) components.

In my case I’m using the Text Layout Framework for advanced stuff, and inside custom controls I’m using the plain old TextField to give me good performance.

The Problem

When you embed a font for the new text engine (and TLF), you need to specify the font to be embedded using CFF (part of the DefineFont4 embedding engine). Usually I embed each font 4 times when I do this, for regular, bold, italic and bold italic variations. The problem is the CFF embedded font is not available to TextFields.

If you run through the Fonts listed in Fonts.enumerateFonts(), you’ll see your Font there, but the .fontType property shows it is CFF. With Flex 4, CFF is set to true by default. Here’s an example of how to specify DefineFont3 embedding using Flex 4:

[Embed(source='ttf/arial.ttf', fontFamily='Arial', unicodeRange='U+2022,U+25A0,U+25C6,    U+0030-U+0039,   U+002E', cff="false")] 
public static var Arial:Class;


This is really just something to be aware of, there’s no much you can do (as far as I’m aware), apart from either embedding the fonts using both CFF and not using CFF, leading to huge SWFs. Or you stick to using non-embedded fonts when using plain TextFields and the TLF everywhere else.

There has been some discussion on this at Adobe and this includes suggestions on how to deal with this transition. It seems the plan is to develop a new TextField class that uses Vellum (the Text Layout Framework).

13 thoughts on “Flex 3/4 Font Embedding: CFF-DefineFont4 vs DefineFont3”

  1. I should point out that if not-embedding your fonts (so that you can use the TLF) seems a pain you can use the blendMode = BlendMode.LAYER to prevent your non-embedded TextFields from disappearing when you mask them.

  2. Hey Richard –

    Have you any experience embedding different cuts of fonts, such as bold, italic and so on, using DF4? At the moment, im in a huge world of pain, having to embed some as TrueType and others as OpenType because the compiler seemingly ignores “italic” on TrueType but picks it up with OpenType!

    Nasty stuff!


  3. Hi Rory,

    Yes I’ve been embedding the various weights and styles using DefineFont4. In the Embed meta-tag I’ve just been using the fontWeight=’bold’ or fontStyle=’italic’ options and I’ve had no problems so far.

    At what point are you finding it fail and how are you testing? (I tended to use a small hand coded portion of TLF XML).

  4. Hey Richard,

    It was failing at compile time, saying it couldn’t find the correct font name, weight, style etc. I ended up having to strip all the meta data out of the font using Font Lab, then exported new fonts as TTF’s, with the style name as part of the font name. Managed to get it working this way.

    I could compile Arial and other system fonts fine, it just threw these errors when i tried to compile a font called Plantin, which had been working fine with DF3 embedding.

    Was compiling using FDT/MXMLC through ANT.


  5. Richard –

    Out of interest, which version of the SDK are you compiling with?



  6. I’m using but I’m still using the November release of the TLF (will upgrade to the nightlies soon but I’m avoiding the API changes for the moment).

  7. “It seems the plan is to develop a new TextField class that uses Vellum (the Text Layout Framework).”

    I think the problem with this will be the performance mentioned before. I ran a couple of really simple tests with the different possibilities to create text, and came to some serious results. The goal was to create 1000 multiline textfields:

    TextField: 187ms
    FlashTextEngine: 944ms
    TextLayoutFramework: 2823ms

    Either my implementation was really bad (don’t think so) oder the actual TLF is more than 14 times as slow as the good old TextField, and the FTE implementation was still about 5 times slower.

    I know that the power that comes with FTE is hillarious and something we ever strived for (no more “no go!” to the designers out there), and it would be fine if you could use TextField and the FTE both, but as you have to choose for one embedding method I have some serious issues about switching to FTE right now…


  8. Actually, in the test mentioned above I used TextFilter.PLAIN_TEXT_FORMAT for the TextLayoutFormat import.
    If importing withTextFilter.TEXT_LAYOUT_FORMAT, it took me 3166ms, which is over 16 times slower than TextField…

  9. Hi Matthias, that’s very interesting indeed. Of course the TLFTextField replacement has already made it into the Flex 4 SDK (on labs), but the performance question is interesting, perhaps something to bring up with the TLF team via their blog to see if there are optimisations planned? Thanks for your comment.

  10. Okay I must admit I did my tests with the actual download of the TLF, not the one incorporated in the Gumbo release.

    I furthermore noticed a mistake in the normal TextField test which affected the performance extremely, because embedFonts had to be set to false (which actually takes more time for the Flash Player)

    The new test results are as following:

    TLFTextField: 77ms
    TextField: 571ms
    FlashTextEngine: 962ms
    TextLayoutFramework RAW: 2285ms
    TextLayoutFramework XML: 2436ms

    So there are slight improvements in the TLF and the TextField is more slowly as its now looking for device fonts. So the FTE is actually only taking the double time of the TextField, which is acceptable for me.

    The results of the TLFTextField would be really astonishing if it would have the same functionality as the original TextField:

    “Due to schedule constraints, for Flex 4.0, TLFTextField will only be usable in limited situations (no htmlText, no scrolling, no selection, no editing)”
    as written here http://forums.adobe.com/thread/453194, so I think it’s nice performance leads back to these missing features.


Comments are closed.