TLFSprite is an alternative solution to starling.text.TextField when needing to render sprites of text from OpenType and TrueType fonts (both device and CFF embedded). TLFSprite uses the external Text Layout Framework engine: http://sourceforge.net/adobe/tlf/home/Home/ as opposed to the classic flash.text.TextField to render text.

NOTE: TLFSprite does not wrap both rendered text and bitmap font support like starling.text.TextField. You would only use TLFSprite to render text from non-bitmap fonts.

NOTE: If you need extended TLF support especially if using Feathers you should check out this TLFTextRenderer code getting active development and extra features: TLFTextRenderer

Additionally, note that unlike flash.text.TextField, which uses non-CFF embedded fonts with embedAsCFF=“false”, TLFSprite (and the Text Layout Framework) need CFF embedded fonts, so ensure your embedded fonts that need to work with TLFSprite use embedAsCFF=“true”.

TLFSprite works in the same manner that starling.text.TextField does to produce the bitmap rendering and subsequent Image and Texture that renders the desired text. While starling.text.TextField internally uses a flash.text.TextField to render and draw into a bitmap, TLFSprite uses the Text Layout Framework engine to generate text line flows that it then draws into a bitmap, allowing the TLF engine to calculate flows and layouts based on formatting properties.

TLFSprite isn't necessarily any faster than using starling.text.TextField to render text, but by using the Text Layout Framework you may be able to better generate advanced typographic layouts, especially when needing bidirectional or vertical text layouts for writing scripts including Arabic, Hebrew, Chinese, Japanese, Korean, Thai, Lao, Vietnamese, and others. There is also automatic line break and constrained composition formatting, along with vertical text layouts that might also be of interest even if you are only working with Western/Latin scripts.

TLFSprite works on Flash, AIR desktop, and AIR mobile platforms. Include the textLayout.swc from the Text Layout Framework distribution in your project as the only additional external dependency to use TLFSprite.

The sample snippet code from https://gist.github.com/3167820#file_tlf_sprite_snippets.as generates the results shown in the screenshot below: NOTE: TLFSprite has the same debug border property that Starling's TextField has, so I just turned the border property on for all the examples below to show how the content bounds is automatically set by the underlying Text Layout Framework.

(The snippet .as file is also included in the gist source download)

You can create a TLFSprite with just a simple plain text string and one or two style changes, or you can get as complicated as the Text Layout Framework allows you to get with custom hierarchies of text flows.

See the Text Layout Framework documentation and the sample online rich text editor example to explore all the many formatting options that can be applied with the Text Layout Framework: http://labs.adobe.com/technologies/textlayout/demos/

• 2012/07/23 22:27: First public version

https://gist.github.com/jamikado/3167820

Question:

If I create new TLFSprite, the actual height is not available. But after a while it is. When the actual height is available? Why calling getter of height after creation throws error?

Answer:

Actual height is available after first flatten() call.

Author's Note: I have no idea why this user Q/A is added here. Flattening has nothing to do with this class, nor is it a requirement to get width/height. Not sure what issue the user is having but they may not be waiting for the rendering to be happening a frame or so later… You certainly don't want to be calling flatten() everytime you use this class.