TextField future in Flash

Future of TextFieldMost of you I guess, started programming with Flash using the TextField API and literally, we have to admit it, you know it by heart today, cause it's been a long time you have been fighting with it :)

With Flash Player 10, we introduced a new low-level API called FTE (Flash Text Engine), and on top of that we built an AS3 framework called TLF (Text Layout Framework) which allows you to do complex layout for bi-directional text with support for international glyphes and more. You end up basically with an engine very similar to what you would find in InDesign, extremely powerful. But by studying what people are using today in most ActionScript projects, you realize that the power of the text engine or TLF is many times not required in most commercial Flash projects. By taking a look at most Flash projects today, it is pretty obvious that TextField is still king even in big Flash projects. So why is that ?

Mainly because people know the TextField API very well, have accumulated tons of helper classes or framework on top of it and have found ways to cover most of their needs (through painful hacks often). Still very little CSS support, but at the end of the day, it works. You would love to use FTE or TLF, but then comes the issue about the size of TLF, and the many ActionScript wrappers you need to code on top of FTE to come up with something similar to TextField cause FTE is so low-level.

So we may need a new API intended to be replacing TextField in the future. A native API, built on the bones of FTE, with its power, but sitting between the very low-level FTE model and the super complete TLF framework. Think of it as a new TextField design, blazing fast, taking in account modern text requirements (bi-directional, international glyphes, modern CSS and HTML support, etc.). Crazy ? Some of of you may think, there we go again, another text API!? Well, again, consider this new API a replacement of the TextField API, not another one. Of course, TextField would always be there for backward compatibility, but just not updated or improved anymore.

So if you are heavily using the TextField API today and have feedback for improvements, if you'd love to use some of the power of FTE but you think it is too complex to use and would rather use a more efficient API, if you are looking for modern HTML markup or CSS support in the Flash runtimes or more generally better text support in Flash, then, let's talk. Post any comment you may have, raise your voice :)

Comments (94)

  1. Nice post. And what’s said about TextField and it’s deep roots in past is entarly true. But I agree, it is time to move on :)

    Wednesday, April 6, 2011 at 12:07 pm #
  2. Let me be one of the first to say: FUCK YES!

    I’ve been longing for a TextField that can do proper HTML, CSS (css inheritance please?) for like…ever!

    This would be heaven. It would also be great if a text selection could automagically return a object containing information if a selection is wrapped in a HTML tag and if that Tag has any additional properties so to give easy access to manipulations.

    Also, webfonts! but no i’m dreaming ;)

    Wednesday, April 6, 2011 at 12:13 pm #
  3. Joe wrote:

    Ok, I’ll bite. I have a couple of issues with the current TextField API.

    1) I need to be able to make fixed size text blocks which only let you type text if the block isn’t full – anything else gets cut off. I’m currently doing this by watching for scroll events, but it doesn’t always work – particularly if you only have one line.

    2) The other thing I need to do is get a list of all the formatting changes on the textfield without using HTML text. I’ve written a function to binary search the field and return the format changes in a list which works ok but it would be better to have it built in.

    Wednesday, April 6, 2011 at 12:38 pm #
  4. Mem's wrote:

    I don’t know if adding an other TextField API is really needed. Actually I’m always use TextField class instead FTE API, I never make the leap to use it and because some frameworks components still using TextField.

    But the day I will use FTE API, I will do it with TinyTLF helper:

    Wednesday, April 6, 2011 at 12:41 pm #
  5. mrgnou wrote:

    You finally put your finger on something I’ve wanted since Adobe released TLF support. You are right, I’ve always been avoiding TLF cause it’s way too heavy for basic usage (by all meanings of the word).

    Problem is that textfield is quite buggy, it is almost impossible to get the right bounds of it (TextLineMetrics is quite incomplete and doesn’t seem to return exact values), there are some positionnement issues in the IDE between mac / pc …

    I’ve been using F*CSS to get a better css support, and I’d really loved to get a better native support of that.

    Bisous en suc’

    Wednesday, April 6, 2011 at 12:41 pm #
  6. John wrote:

    TLF has two serious problems that need fixing – the loaded swf bug that prevents you from referencing it’s base class, and the fact that TLF publishes an extra file that needs deploying along with the swf, making it unusable in certain circumstances.

    Surely it would be better to add new features to TLF once the bugs have been fixed? And leave textfield as it is so that we have a reliable option to fall back on if TLF doesn’t work?

    Wednesday, April 6, 2011 at 12:48 pm #
  7. Ideas well, I think we always appreciate more simple API’s. CSS support of course, the idea of using directly from an html source would be nice.
    An other topic is render problems(sizes/bold..) or avoiding flash crashing all the time when working with different font’s, specially mac/pc cases. Can you make it work well?..please? :)


    Wednesday, April 6, 2011 at 12:55 pm #
  8. Yes, a thousand times, YES! Everything in your post is on target.

    How about this for a crazy idea: Flash have an API for using the same html/css box model system as the rest of the internet. Crazy right?!

    By the way, if you want to read more about working with TextField, check out the tut I wrote at:


    Wednesday, April 6, 2011 at 12:59 pm #
  9. Burak KALAYCI wrote:

    ‘TextField would always be there for backward compatibility’

    I don’t think ‘being there’ is enough for backwards compatibility. If you will not be fixing bugs (for future SWF versions) then you will be just dropping the feature.

    So the question will be, when will you drop the replacement API for the better API next time, which will be replaced next…

    For backwards compatibility, you need to keep supporting the feature by fixing bugs. Announce the feature deprecation ahead of the time, like at least a year, keep fixing bugs for a few years more, and fix security bugs as long as the feature is there.

    When you do not value backwards compatibility, in the long run, devs will see that they can’t trust any API or feature of Flash being supported (in the real sense – not just being there) and they won’t commit themselves. And when that time comes, there won’t be an easy way to recover from that.


    Wednesday, April 6, 2011 at 1:23 pm #
  10. lee-o wrote:

    Hi all,

    • Easy RightToLeft support, today for arabic language we’re using flaraby on custom home made classes supporting textFormat and external font loading, really painfull but not so as TLF

    • Ok with mrgnou, TextLineMetrics is really buggy

    by the way, the new flash player rulesssss

    Wednesday, April 6, 2011 at 1:40 pm #
  11. MSFX wrote:

    Glad you’re looking at rewriting this, it’s been long neglected I feel.

    TLF is great with what it can do but with its weight it just isn’t usable except for with desktop etc.

    I find there are bugs with the textfield as soon as you start to apply any form of textformat or stylesheet to the textfield, particularly if there are hyperlinks present – the text all jumps around when the mouse enters its bounding area. Text field size is also always based on guess work I find.

    Better CSS support for styling of text and positioning any images / elements etc within the textfield would be great.

    Support for basic html tags such as table would also be welcomed… maybe the HTML5 video tag would be a good one too ;) lol


    Wednesday, April 6, 2011 at 1:41 pm #
  12. sascha wrote:

    Uhmm actually the reason why nobody is using TLF is because of it’s awkward implementation as a runtime shared library. Feature-wise it’s definitely a keeper (if it’s performance could be improved).

    Wednesday, April 6, 2011 at 1:45 pm #
  13. Pleh wrote:

    This may not be directly related but I would really like to be able to render text onto a bitmap. Maybe something like…

    bitmapData.DrawText(x,y,”Hello World”, new TextFormat(“Arial”, 12));

    Wednesday, April 6, 2011 at 1:48 pm #
  14. We’ve been using TLF heavily since its early betas in our flex project (we needed RTL support).
    I can’t agree more that it’s too complex and not easy at all. And its customization can become a real burden in certain situations (think context menu for a specific word). You can do a lot with TLF, but at a price.
    Also, the performance of TLF leaves a lot to be expected. It’s slooow, especially for big chunks of formatted text. It’s acceptable for displaying text, but when it comes to editing large blocks of text it’s really slow.
    As for the TextField refresh you’re talking about, I personally vote for richer HTML support and ability to properly insert images into the field.

    Wednesday, April 6, 2011 at 1:52 pm #
  15. Nicolas wrote:

    1. Texfield gaps. Its really boring. Let developer control any margins and paddings. Let say I have design where various text blocks left aligned and have custom styles (30 pt title, 14 pt date). But Textfield has various gaps with 30 pt font or 14 pt.
    P.S. Remove any inner gaps at all. So if I set x = 2 result 2 px margin not 6 px as example.

    2. True width and height properties. So you don’t need +x px offset so Textfield looks ideally at middle.

    3. Gradient fills.

    Wednesday, April 6, 2011 at 2:22 pm #
  16. Very important point. There are many new features that we want in text with flash. But before we need to fix some terrible bugs:

    1. The ones pointed above: bugs on size/postitioning between pc/mac, CSS horrible, poor HTML support.
    2. By the way,HTML must be 100% supported. I want render “ação” and not “ação” on screen. It is important to languages other than english. And gives a big headache who nedd it today. Actually i have to use different webservices (or special treatments on server side) on my web apps because flash just cant render my html entities properly. Shame on Flash. How can a web app cant handle HTML content??
    3. Everybody complains about TLF size. Yes, we need something intermediate between TextField and TLF. And more reliable control over texts widths, heights, lines.

    4. Have you ever tried to “fit” a big word onto a text field? I usually work with multilanguage flash content. So in english we say “go” and in portuguese we say “iniciar”. It causes big problems in layout. Nowadays I have my custom algorithm to “reduce” the font-size until the sentence fits the text-field without “cut” letters, create breaklines. It should be a native method. And not just for “single line” textfields (because with multiline, the text height is buggy….).

    Well, thank you for your great article and for bring light on this matter. Sorry for my poor english. Textfield in flash is something that needs urgent improvements. Glad to see that you can see it.

    Thank you.

    Pedro Paulo Almeida
    Flash Developer – Brasil

    Wednesday, April 6, 2011 at 2:30 pm #
  17. pete shand wrote:

    for myself, I never transitioned to TLF because of the extra file size, it just seemed crazy that it wasn’t packaged with the flash player, i also ran into issues with importing shared libraries while using TLF.

    That aside, It’s great to hear the textfield may be revised!

    On a side note do you have any statistics on the percentage of flash projects which use classic tweening rather than the new motion tween engine? It would be interesting to see if it has followed a similar pattern.

    Wednesday, April 6, 2011 at 2:47 pm #
  18. Yotam Laufer wrote:

    I second Pleh, drawing text directly to bitmap will be very useful.

    I think that a simple interface such as:

    TextField.text = “”;
    TextField.css = “”;
    TextField.columnCount = 2;

    etc will be super useful.

    Wednesday, April 6, 2011 at 2:51 pm #
  19. I myself have never moved on to TLF, for many reasons, one being the bulk of it and that it was really overkill for most projects, but TextField is a pain in the ass too, it is very buggy and quite often hair pullingly frustrating (may explain my baldness??) when doing in nothing but code (works well in the IDE though). What it is really missing is better html and css support, it would be great to be able to style all of the text in a flash app from an external style sheet and through more (un-deprecated) html tags – now that would be powerful!

    Wednesday, April 6, 2011 at 2:57 pm #
  20. Hadi Tavakoli wrote:

    TLF main problem is surely it’s huge size. besides, it’s very tricky to embed fonts in code (not embeding through the CS5 IDE)

    few months back, I tried to do a project with TLF, but I finally decided not to, because I found it too buggy! or maybe it was too complicated that I thought it is a bug?!

    The point is that I have lost interest in using it and I do hate this choice I made, but what can I do? time is money, you can’t just build up your project with some tools that will make clients get back to you with tones of questions, right?

    Wednesday, April 6, 2011 at 3:18 pm #
  21. Philippe wrote:

    Personally, although I understand some of the technical reasons, I can’t agree with having to embed 2 fonts, one for TextField and one for TLF. Also the fact that TLF layout isn’t native but AS3 is plain silly imho.

    Now for TextField that we love and hate, some improved and more complete CSS support and better images positioning would just be enough for 99% of our text needs.

    Wednesday, April 6, 2011 at 3:28 pm #
  22. Bart wrote:

    Sounds good, but whatever solution you develop, please don’t construct a mess like with the TLF .swz preloader shimthing horror.

    It’s sort-of-workable if you start a fresh project and use TLF from the start, but if you have to upgrade a large existing application to support TLF text then you’re in deep trouble (rewrite every TextField utility/behaviour, re-architecture the loader infrastructure, go insane on RSL’s etc).

    An updated TextField with Flash Player integrated code and no interfering with other aspects would be very welcome.

    Wednesday, April 6, 2011 at 3:32 pm #
  23. I need a better html layout effects.
    More support to the Layout tab.
    For example,
    div, free to set the rendering coordinates.

    Wednesday, April 6, 2011 at 3:53 pm #
  24. Rackdoll wrote:

    Really nice to see the text engine is getting updated…
    So this does mean we will have html5 support ?

    Wednesday, April 6, 2011 at 3:59 pm #
  25. me wrote:

    I use TextField, because it does not load any SWZs. With TextField axed, what will be my options?

    Wednesday, April 6, 2011 at 4:16 pm #
  26. Ozzy wrote:

    TLF issues with importing shared libraries (and with no documentation to tell us how to get around it) is a pain.

    I agree with other comments that TLF layout needs to be native.

    Also… that text rendering bug with mac os x 10.6.whatever….

    I love the features of TLF, but something simple that we run into on many projects, which is missing, is just the plain old ability to add a stroke to dynamically rendered text.

    Wednesday, April 6, 2011 at 4:34 pm #
  27. Big Al wrote:

    @Pleh NewsFlash: you have that already through BitmapData.draw().
    var bm:BitmapData = new BitmapData(200, 80);
    var tf:TextField = new TextField();
    tf.text = “Hello”;

    Wednesday, April 6, 2011 at 4:34 pm #
  28. Vic wrote:

    FTE is slow, so a good practice is to avoid it.

    The minor improvements for Text field:
    - Smaller when embedding the font or better more fonts embedded in the flash player.
    - Extruded/3D. Away3D has an extruded font api. When you watch tv, most of the time it is a 3D/extruded font.

    At least don’t make it worse. There are other things I think ahead to make FP better.

    Wednesday, April 6, 2011 at 5:04 pm #
  29. Olivier wrote:

    What I find hard to do with the TextField API is metrics. As mrgnou said, TextLineMetrics is incomplete and inaccurate. Metrics are important because designers use Photoshop or Illustrator to align text with other graphical content. It’s easy for them because usually they use lorem ipsum, so they just align the text manually. When I build the user interface, I can’t do that, since the text is usually dynamic.

    I don’t even know what’s possible with FTE, but something like this would be very helpful : http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/FontHandling/Tasks/GettingFontMetrics.html

    Wednesday, April 6, 2011 at 5:11 pm #
  30. zeh wrote:

    I’ve tried migrating to FTE completely. Lately what I’ve been doing for personal and commercial projects is a mix.. my own TextField-emulating “TextSprite” and “RichTextSprite” class, based on FTE. My own class is good, but is missing some features like CSS parsing and better style support (like TextField).

    I find FTE to be very powerful, although I still miss the sharpness/thickness control of the old TextField renderer.

    The biggest problem is still editable textfields… I’ve tried wrapping around FTE but there’s a lot of limitations (like having to emulate copy & paste, and no way to properly detect an UNDO shortcut – no events) that end up making the task unsuccessful. So I still use an “EditableTextSpriteLegacy” class for editable textfields (which is a problem since I need one additional, non-cff copy of the font embedded).

    I haven’t looked into using TLF. To be quite honest, many times I’m just bummed by the size and additional APIs involved by Adobe’s own frameworks, so I end up building something myself just so I can tweak and add to it until it just does what I need. Same thing with Video classes, for example.. FLVPlayer, OSMF, whatever – I just end up using my own that uses a NetStream and a Video instances and then adding features as I need.

    With that said, I think the solution’d like to see from Adobe is an easy TextSprite, built on top of FTE, but with proper, more powerful CSS support. CSS support that is good enough for us to build a real HTML renderer. Editable too, and with a very, very small additional API. I know Adobe’s own libs must make a lot of different kinds of developers happy, so I wonder if this at all possible. But that’s my point of view.

    Or rather I’ll just take some time to refactor my own TextSprite to finally add CSS support and hack some editing features.

    Wednesday, April 6, 2011 at 5:46 pm #
  31. Samuel wrote:

    I agree with Vic. I don’t understand how such a new API would be “blazing fast”, since FTE is much slower than TextField.

    I’d be glad if there was a simple, easy-to-use yet powerful and bug-free way to display simple texts, like we all do 99% of the time.

    But with the current state of FTE, it is nowhere near “blazing fast”. It’s more like five to ten time slower than TextField. I’m kinda worried that you – as the Product Manager on the Flash Platform – are not aware of this fact.

    Wednesday, April 6, 2011 at 5:48 pm #
  32. Bart wrote:

    Something related: please improve font-embedding and sharing. Right know it’s such a mess.

    I had to explain a junior all the stuff you have to do to reliably use embedded fonts in applications using multiple SWF’s (compiled both from IDE and FSCH) while not bloating files with duplicate glyph definitions, then setting the gazillion different names for definition, class, style, allias and whatever is in the ttf/otf file and using that in TextFormat and CSS.

    And then the fun only begins. Once you introduce different Application and Security domains and non determined ordered loading (depening on the order you load font definitions get overriden). All nearly invisible and very time consuming to debug.

    And he looked at me as if I was going insane. He was right.

    This was with gool ol’ standard issue TextFields. I didn’t bother going into TLF.

    Wednesday, April 6, 2011 at 5:56 pm #
  33. thienhaflash wrote:

    Great news, finally !

    I’m not trying to insult the hard work of anyone here, just trying to tell the truth so please don’t get offense.

    The fact is : TLF is too heavy, unnecessarily complex and poorly designed.

    Why should TLF be that heavy ? why things i never use got imported ? Some kind of dependency aware will make things better, let classes be loosely coupled, and group into small chunks then embed only the part we actually used.

    TLF someway altering the Loading process (trying to load the swz first) even make things worse – we got the wrong loader.content or we should perform additional (unnecessarily) checks. Why interfere with my loading process ?

    TLF didn’t extends from TextField which cause a big barrier trying to get supported from existed libraries.

    Something we can do :
    For any function you want to have, add it as new functionality of the TextField class or at least extends from TextField (we may need to rewrite the TextField class then ?)

    Don’t trying to alter the loading process – let the player load it silently by passing some special values to it may be a trick to consider ? If the user choose to embed the TLF in the swf itself then we need to check the functions we actually used and import only the chunk that contains these functions.

    Better HTML / CSS support. Although native HTML render is almost impossible trying to keep up with the mostly used functions. Currently, the TextField’s texts sometimes move back and pro

    A tool for automatic font swf creation : Let we choose a folder of fonts, convert them to swfs.

    Fonts should never gets embed into the main.swf file, while playing main.swf on user’s computer, the player should check whether the necessary fonts used in main.swf existed in user’s computer or not and load the absent fonts (we may need to specify fontPath when compile the main.swf)

    What do you think ? are all these doable ?

    Wednesday, April 6, 2011 at 6:00 pm #
  34. I have beaten this horse to death and beyon. To sum up my views on some of the major failings of TextField and StyleSheet classes I would like to turn your attention to my post from 2009 on the topic. At the time I was trying to fix the missing functionality of the StyleSheet class which eventually grew into my F*CSS project:


    Wednesday, April 6, 2011 at 6:05 pm #
  35. Tim Scollick wrote:

    I love the text field improvements in CS5 (thank you) but I have a bone to pick with Flash’s product direction.

    Do you know what I would kill for? A version of Flash that didn’t crash on me every day. Adobe needs to stop adding features and fix the ones that they have.

    Where do those bug reports that we submit every time Flash crashes actually go? Does anyone read those and fix the bugs?

    Wednesday, April 6, 2011 at 6:10 pm #
  36. /*
    TLF has two serious problems that need fixing – the loaded swf bug that prevents you from referencing it’s base class, and the fact that TLF publishes an extra file that needs deploying along with the swf, making it unusable in certain circumstances.

    TLF is non-starter until this is fixed.

    Wednesday, April 6, 2011 at 6:19 pm #
  37. Thibault Imbert wrote:

    Hi Samuel and Vic,

    We know about the speed problem, hence why we start this initiative.

    When I say, built on top of the FTE, I mean built on top of the internal framework used by FTE. This does not mean an API extending or built on top of TextLine or TextBlock.

    A new design fixing the current decisions we made making the current implementation too slow and low-level. Think of it, as a TextField friendly interface with the underlying power of the text engine.


    Wednesday, April 6, 2011 at 6:36 pm #
  38. Thibault Imbert wrote:


    I fixed the wording by “built on the bones of FTE” to avoid any confusion ;)


    Wednesday, April 6, 2011 at 6:55 pm #
  39. What I want most:


    [x] True HTML5 + CSS – it must be able to pass all tests used by the web browsers (acid, etc).

    [x] Must be able to gracefully handle poorly formatted and invalid HTML so we can include html from our php scripts that was typed in by newbies etc.

    [x] True HTML5 with CANVAS and javascript would be great – this way game developers could package their HTML5 games in a container format for easy distribution and game licensing.

    [x] Simplicity is better than feature-richness.

    Keep up the wonderful work! Thank you!

    Wednesday, April 6, 2011 at 7:05 pm #
  40. Richard Marquez wrote:

    Getting the exact height/width of the text inside a TextField. It’s very buggy actually and I’ve fight a lot to make an auto-resize component.

    I would also like a textfield that displays the text with rotating/scaling under certain circumstances.

    Wednesday, April 6, 2011 at 7:07 pm #
  41. Philippe wrote:

    I’ll add one note: making TLF font embed the default in [Embed] tag since Flex 4 was a terribly confusing change.

    Wednesday, April 6, 2011 at 7:16 pm #
  42. Good lord just reading about TLF really grinds my gears…the time I’ve wasted dealing with it and it’s horrible APIs makes me want to kick something. If it were an actual, physical thing, I would totally go “Office Space” on it and beat it with a bat.

    I get it that it might offer “fine typographic controls”, but I didn’t ask for that and don’t need most of it. I just want to display some formatted text.

    Wednesday, April 6, 2011 at 7:21 pm #
  43. Alex wrote:

    It would be great if the learning curve could be lessened for newcomers. Font embedding is always a problem, especially outside of CS. Managing the size of TextFields is also a real pain when learning. Either the TextField doesn’t expand to let you see the text, or it takes up way more space than you think it does and causes container objects to resize in unexpected ways. These are things you can get around once you know what you’re doing, but many people don’t, and these serve as areas of frustration.

    Wednesday, April 6, 2011 at 7:22 pm #
  44. Adam Luptak wrote:

    Until recently, I’d avoided TLF purely out of inertia, but it found its way into my latest project for a while. Part of the working process of the project included laying out elements in Flash IDE and pulling them into an Actionscript project as .swcs.

    I love the look of the TLF – seems to render more clearly – but I noticed that importing TLF fields through a .swc never garbage collected. Bad form to begin with, and this particular project is an AIR app that needs to run well for 18+ hours straight, creating and destroying DisplayObjects and TextFields all day, so memory leaks were a complete non-starter.

    So yes – I would love new TextField system. Personally, my primary concerns are quality of rendering, stability, and memory usage. Everything else is gravy – nice to have, but not ultimately worth much if the basics aren’t in place.

    Wednesday, April 6, 2011 at 7:26 pm #
  45. Pascal wrote:

    Mieux vaut tard que jamais !

    Wednesday, April 6, 2011 at 7:43 pm #
  46. This is a great post. I felt very emotional when i read it. It feels like Adobe really listens. We certainly need upgrade for Textfield.

    Wednesday, April 6, 2011 at 8:09 pm #
  47. tyler wrote:

    simplicity is key,
    var txt:TextBox = new TextBox();
    txt.text = ‘my text’;
    This has to just work in every case and the defaults have to make more sense, you shouldn’t have to set multiline, wordWrap, width, autosize or anything else. It shouldn’t need to have it’s methods call in a specific order or break if it doesn’t have something. Text should always be displayed and if there is a problem events should be dispatched with information about how to fix.

    About HTML and CSS, if you can do it right that is great, if you can’t then keep it simple, support tags that can have ids and classes that can have CSS styles to set the format, bold, italic, underline, color, background-color, selection-color, font-size, leading, line-height. Don’t bother with the positioning or making tables or list unless you are going to do it right. Fancy selectors are not useful in a simple system like this. But include anchor hovers, and not just globally, you need more than one hover style.

    Also you can have image tags now but not in AIR, this is lame, just take all of this out. Make a way to block out an area and have the text wrap around, give us the position of this block or let us set it and we can place whatever we would like there. We need events if these blocks are reflowed or change.

    Fonts are a major issue but I’m sure this is out of the scope, the only thing we really need is Font.unregister()

    Wednesday, April 6, 2011 at 8:18 pm #
  48. Improved CSS support, improved HTMl support. I can understand if it’s not HTML5 complete. I mean you can’t bundle a browser inside the player.

    Better inline image support, so you can truly wrap text around an image easily.

    Allow an image nested inside an anchor tag!

    Enable bitmap smoothing on an embedded image easily.

    Allow us to change the bullets used in lists!!!

    Be able to specify top and bottom margins in regards to the textfield background. Can only control side margins currently.

    Fix text metrics because they are totally broken.

    Simple column or ‘spill into next textfield’ API. I’ll sometimes just want a simple two column text and i have to import 300k and rewrite half the code just to get TLF to work with it.

    And keep it FAST, TLF is a beast when you need something small and quick AND one unique feature (i.e. columns)

    Thursday, April 7, 2011 at 1:06 am #
  49. Benny wrote:

    I have done a lot of work extending TLF in to something that would work for our customers. We came to the conclusion that TLF is to big and awkward to extend, to much final classes for example and not suited for the mobile platform.

    So next we started to built our own engine on top of FTE. This is an awful lot of work which is again IMHO made unnecessary difficult because of the final classes in FTE. I understand that final classes are faster but isn’t there another way? …e.g. allow extending of a final class BUT with the requirement that the extending class itself is final?

    Unfortunately my company is thinking about moving away from Flash and focus on Android development instead. Because of that our text engine project is on hold.

    In regards to the (not so) good old TextField. I never really understood why the many bugs (e.g. regarding floats) that have been in the TextField for many many generations never got fixed. Backwards compatibility probably? But maybe we should just agree that hacking around bugs means unhacking when fixed in a following release or don’t use, because Adobe promises to fix it A.S.A.P in a few days!

    Maybe the time is right to let the Flash Player grow a bit more in size and embed Webkit in it. Allow it to be run in read, select and edit mode and everyone will be happy. How much size would this add to the download? Would be acceptable for the vast majority of users?

    Thursday, April 7, 2011 at 1:13 am #
  50. Very good news, TextFields to me are one of the most annoying things about Actionscript 3. There are tons of properties that need to be adjusted for even moderate use, and TextFormat can be long. I also don’t like how messing with the z-depth of text fields (Even textField.z=0) blurs them. Plus, the sizing of TextFields is a pain also. Anyway, glad to here an improved version is coming!

    Thursday, April 7, 2011 at 2:12 am #
  51. We tried to move to TLF once, but found a major memory leak that resulted in a fair bit of lost time. I haven’t checked recently, but when I last looked it was still there. My one wish is better text format APIs, character index are thrown off by them terribly when using htmlText, this makes it hard to do dynamic styling with multiple formats on a single field.

    Thursday, April 7, 2011 at 2:50 am #
  52. Tim Keir wrote:

    I posted a bunch of things ages ago on Adobe Labs Idea’s for Flash Professional however the site seems broken at the moment and won’t let me view past the first page to link to them. http://ideas.adobe.com/flashpro

    1. There was a glitch introduced in FP10+ when using autosize = “left”;, embedFonts = true; and
    antiAliasType = “advanced”; together.

    Basically the last character of the TextField gets clipped. This is most visible if you apply a border, however it’s most frustrating when trying to obtain the TextFields width in order to position objects to the right of it dynamically based on the text width.

    As a workaround I check the flash version and apply a space at the end in FP10+ however this is less than ideal.

    2. Another thing I would love is standardisation between the text tools in Photoshop and Flash IDE in regards to leading/kerning, anti-aliasing, and maybe even the addition of faux bold and All Caps since designers seem to use it often.

    I realise I can force toUpperCase() using AS3 however it would be handy in the GUI. Also how am I supposed to match a font from a PSD in Flash if the metrics differ e.g. Kerning/Tracking 100 in Photoshop = Letter Spacing 1.3 in Flash IDE. How am I supposed to know this? Is there a formula other than trial and error? It seems to differ from font to font too. Exposing a method in AS3 to set kerning to 100 to match Photoshop would be great. Or perhaps exposing a method to calculate the correct letter spacing value if you feed in a Photoshop value?

    3. How can you match how a font renders in Photoshop vs Flash. E.g. If a designer selects Strong Anti-aliasing how am I to know that in AS3 I need to set thickness to 150 and sharpness to 200. Again this seems to differ from font to font. I feel we need a bunch of helper methods added in AS3 or else standardise the values to match Photoshop. Preferable a GUI version to compliment any AS3 changes you make to the TextField API.

    Thursday, April 7, 2011 at 3:04 am #
  53. Tim Keir wrote:

    I found the link: http://ideas.adobe.com/ct/ct_a_view_idea.bix?c=6D2B3E83-E9E6-4F44-BFB4-F99CBC0646AE&idea_id=40F8ADFC-C5CB-47F0-A007-15656AFECA3B

    Thursday, April 7, 2011 at 3:07 am #
  54. Vivek Gupta wrote:

    In my current projects we have used TextField heavily.
    Wishlist for new TextField :)
    1. Property to get width and height of actual text. (Its not about TextFieldHeight and TextFieldWidth. For e.g. small “w” is less in height than caps “W”). We managed this calculations by creating BitmapData of this textfield and than counting coloured pixels, but its heavy on performance.

    Thursday, April 7, 2011 at 8:06 am #
  55. Thibault Imbert wrote:

    Hi Burak,

    Yes, we will always maintain TextField, security wise, but we will not fix bugs or enhance the API. We cannot remove it, at least we never did that and we do not plan doing this.


    Thursday, April 7, 2011 at 8:51 am #
  56. Evan Worley wrote:

    How about making precise text rendering actually work well in Flash? I worked on an application in which we needed every character to have an exact floating point width. We embedded a fixed width font for the character width, and were hoping to get the rest using letter-spacing. See https://bugs.adobe.com/jira/browse/SDK-22669. For a company who clearly cares about text and layout, you’d think the implementation would be extremely powerful and not amateur.

    Due to these issues, we had to do tremendous hacks to get the precise rendering that was required, which resulted in an order of magnitude more text objects and hence bad rendering performance :(.

    - Evan

    Thursday, April 7, 2011 at 9:26 am #
  57. This is good to hear, because FTE is really complicated in some ways. However, it’s the fastest possibilty to do text-related stuff in Flash and, if I understand you right, it will always be, because your new API will just use FTE. It will just be some more code in the playerglobal.swc, but nothing new in the FP’s Core – or did I misunderstand that?

    I would like to see a little improvement concerning the way how Fonts are saved inside a SWF. As we all should know, Fonts exist of curves. These curves can be used to produce text at 8Pt, 14Pt, as well as 300Pt.
    Flash projects don’t need the ability to produce 300Pt texts most of the time ;)
    It would be cool, if there was an ability to reduce the quality of the fonts, so that an “R” letter in Tahoma does not contain 40 control points, but instead just 15-20.
    This could reduce filesize dramatically. But I’m unsure about how the implementation would look like.

    Thursday, April 7, 2011 at 9:53 am #
  58. Thibault Imbert wrote:

    Hi Daniel,

    It will actually be a new “native” API, so core to the player but built on the internal framework that we use for FTE. So not the same design as FTE but built on its bones, giving us a lot of its power but through a different implementation, faster, simpler to use and more efficient.


    Thursday, April 7, 2011 at 10:00 am #
  59. Samuel wrote:

    Hi Thibault,

    Thanks for the clarification! I’m glad I was wrong about your vision of the FTE performances. ;)

    If the performances of this new implementation can be as good (or even better) than TextField performances, this would definitively be an amazing improvement. Even with the same features set as TextField, simply without the bugs.


    Thursday, April 7, 2011 at 10:44 am #
  60. jloa wrote:

    Well, the FTE is a nice low-level api as u’ve mentioned, but still is yet complicated for day-a-day simple tasks (single labels, simple dynamic text titles etc). Moreover, using the fte api for such tasks leads to importing the whole fte.* lib, which in turn will lead to filesize increase.

    ps: though i hate the tfs for lack of css support and tons of bugs ^_^

    Thursday, April 7, 2011 at 10:58 am #
  61. Max Oizo wrote:

    Please, add Font.load(URLRequest) for loading native OTF & TTF fonts. It would be very nice.

    Thursday, April 7, 2011 at 11:21 am #
  62. Norbz wrote:

    This is a perfect analysis of what happened at work, we did have tons of framework around and barely have a look at FTE / TFL…

    Imm looking forward this new textfield !

    Thursday, April 7, 2011 at 6:49 pm #
  63. michael wrote:

    I was sorely disappointed by TLF. Just as disappointed as I am in flex, and for the same reasons. For example, when the newer flex components were introduced as lightweight and faster than regular flex components, at a flash conference the speaker had nothing to say about the fact that any project using them would actually be BIGGER. In using those components, it relied on all the previously existing code being there, without ever using it. There’s no reason to bring all of flex in when you only need a piece of it.

    I really don’t understand why Adobe seems so in love with flex; having been in the industry for a while, I ask around sometimes to see if anyone is using it. The only person who spoke positively of it, said it was easier to give a jr dev a flex project where they just mess with mxml than expect them to write code. I have never seen a robust, high quality application built primarily with the flex framework.

    Regarding different text handling, I’ve written some very basic textfield-like classes using the FTE, and I don’t understand why no one has gone and reproduced an upgraded Textfield with FTE. It shouldn’t be more than 10-20k in a swf for such an animal. Admittedly, there would be a lot of parsing to figure out… I would have gone this route if I were still programming flash and needed advanced typography in any application.

    Having worked with TLF in the exploration phase of building an application framework, I would not recommend its use unless it were used solely in an AIR app and under a limited budget.

    Thursday, April 7, 2011 at 8:06 pm #
  64. Bear wrote:

    Are there plans to improve the performance of the FTE? We have been using it as the basis for our own layout engine, and appreciate the low-level power, but it is a major performance drag on our project.

    Thursday, April 7, 2011 at 8:11 pm #
  65. Thibault Imbert wrote:

    Hi Bear,

    Yes, the idea with his new API would be to really focus on performance. So you would get the power of FTE but without its performance issues through a different design an API.


    Thursday, April 7, 2011 at 8:18 pm #
  66. fr wrote:

    Are drop caps available in TLF ? (or FTE), i don’t find in the UI.
    And we’d need some “tab indent at cursor” character as indesign (i make bullet points and i don’t want to have to know where i start my bullet point)

    Thursday, April 7, 2011 at 10:21 pm #
  67. Your assessment is right on! This is exactly the issue we have and why we continue to use the TextField class. But, localizing text is a huge concern for us. Perhaps review other engines and API’s that already offer such functionality and imitate the best one?

    Friday, April 8, 2011 at 7:23 am #
  68. workerdrone wrote:

    My team investigated and were excited about TLF right until we discovered the file size overhead. That killed the discussion right there in the same way that Flash Catalyst not being able to roundtrip assets back to Flash Builder easily (until perhaps maybe possibly Panini comes out) killed the discussion about even learning Flash Catalyst or taking it seriously. TLF is great and we need better text but it needs to be a lightweight solution.

    Friday, April 8, 2011 at 9:40 am #
  69. thanks for the clarification. ok, now i’m even more thrilled :)
    is there an ETA and/or prerelease team to participate in?

    btw. the way the flash-team is currently going is really great. there’re so many nice features coming that were requested by many devs. thanks for listening to us ;)


    Friday, April 8, 2011 at 10:33 am #
  70. viaria wrote:

    very true, and the replacement is very cool. another one can be confusing. Thanks.

    Friday, April 8, 2011 at 2:28 pm #
  71. jloa wrote:

    “Please, add Font.load(URLRequest) for loading native OTF & TTF fonts”

    TOTALLY for it! Tired of using external swfs with embedded fonts

    Friday, April 8, 2011 at 9:22 pm #
  72. Héctor wrote:

    I don’t work too much with text, but all the times I’ve worked with the classic TextField class, these are the main things that bothered me and thing should be there:

    - Being able to get accurate text width, height and number of lines.

    - A property to set the text vertical alignment.

    - The lack of proper RTL and top to bottom text.

    - Some way of rotating and set the alpha of a text without having to embed fonts.

    Also, it would be nice to be able to load some external fonts. I don’t know if the format is a problem per se, but maybe there is some open source format that could be used and let people convert fonts in other formats.

    Saturday, April 9, 2011 at 12:42 am #
  73. Emil wrote:

    I think the first thing to focus on would be to have the same exact capabilities as TextField but getting rid of the bugs.

    Some of the issues I’ve encountered include:
    - pasting text into a TextField on a mac causes all line breaks to be stripped out.
    - fonts with glyphs that extend past the bounds of the TextField get cropped off
    - no way for user to enter tab character into Textfield without checking for it and replacing with tab character

    Certain features that seem pretty basic but are missing include:
    - easy way to check to see if text fits in visible area
    - easy way to get line formatting by character position

    It would also be really nice to have better font handling like being able to unregister fonts on the fly and stream font glyphs without embedding fonts into swfs and specifying sets of glyphs for embedding in advance.

    Saturday, April 9, 2011 at 1:19 am #
  74. To #54 Vivek and Héctor, a textField does have a textWidth and textHeight property which I think is what you are looking for. http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/text/TextField.html#textWidth

    Saturday, April 9, 2011 at 1:57 am #
  75. A fabulous achievement would be to be able to perform this very basic functionnality in the IDE, like to be able to put textfields on the stage with TTF embed, that would display the very same way on Mac and PC. Cheers.

    Saturday, April 9, 2011 at 12:48 pm #
  76. Héctor wrote:

    The textWidth and textHeight properties don’t give accurate values in a lot of cases.

    Saturday, April 9, 2011 at 11:12 pm #
  77. @Héctor
    Oh don’t they? Is there certain things that cause this? Thanks for letting me know

    Sunday, April 10, 2011 at 4:09 am #
  78. Vivek Gupta wrote:

    I am looking for exact pixel level width and height of text nor the textfield height and width.
    For example if I have entered “w” or “A” in textfield the TextFieldHeight will be same. But in my requirement height value should be small if I entered “w” and height should be more if I entered “A”.

    It should be textheight/textwidth nor the textfieldheight/textfieldwidth.

    Sunday, April 10, 2011 at 10:11 am #
  79. _equ wrote:

    Some feature requests:

    * Addition of “Native link area would be nice: Region outlined by text/shape that will be treated as regular html link on the webpage so user will be able to bookmark it, open in the background, use browser context menu etc. (lack of this feature is probably one of the most annoying thing in flash from user perspective).

    * TextField should have a method/property that says whether given text will fit into given dimensions or will be partially invisible/truncated (of course in the case when autosize property set to False)

    * Truncation option and behavior should be easily configurable (add or not ellipsis, use fade out instead of ellipsis {like on the cellphones with android}, get whole text, get only visible text, get only truncated part)

    Sunday, April 10, 2011 at 1:15 pm #
  80. Héctor wrote:

    I’ve often found that adding the font size * 0.8 (or something like that, don’t remember the exact value) to the textWidth and textHeight values gives the expected size, however it’s somewhat tedious when a textfield has several formats applied to it.

    The “best” solution I’ve found so far it is to draw the text to some bitmapdata instance and get all the pixels of it. I’ve seen it’s a technique more people use.

    As I’ve said, I don’t work much with text, I don’t know if I could be missing something.

    Sunday, April 10, 2011 at 7:58 pm #
  81. Pleh wrote:

    @Big Al

    I’m aware that you can get text on a bitmap by rendering it onto a TextField first but I would prefer to cut this step out to enhance performance.

    I have been doing some iphone development in flash recently and even TextFields are horribly slow. Direct bitmap font drawing should help solve this problem.

    Monday, April 11, 2011 at 11:21 am #
  82. Tronster wrote:

    Read all 80+ comments and I echo many of the following in order:
    1. Better text metrics than TextField
    2. Maintain a simple interface (tf.text=”foo”;)
    3. Better styling (TextFormat and defaultTextFormat themselves are not straightforward enough for when they are applied.)
    4. Updated HTML & CSS support

    (My background: I’ve done a lot with TextField in AS3 and AS2. I have not used TLF yet, mostly due to perceived community rejection from implementation complexity. My most complex TF-related code on the net: http://wonderfl.net/c/6GwW )


    Tuesday, April 12, 2011 at 9:21 pm #
  83. Weyert wrote:

    I would love to have an improved text field which allows you to change the presentation of the caret and how the selection rectangle is drawn.

    In such manner you dont need to use a static textfield and draw your own selection and caret indicators. Only because you want to have fade in/out caret. Of course, this breaks copy-paste functionality of the native input textfield :(

    Thursday, April 14, 2011 at 9:58 pm #
  84. Ben Garney wrote:

    Give me some building blocks:

    Good fast unicode-aware text render to a shape’s .graphics and to a BitmapData.

    Unicode normalization (so I can deal with decomposed codepoints).

    Unicode string metric calculation (width/height/ascent/descent of a character and metrics for a string too).

    I can do my own text flow, positioning, etc. Don’t need a framework for that. Just give me a few building blocks!

    Thursday, April 14, 2011 at 11:35 pm #
  85. Aristophrenia wrote:

    Thibault – please – the issue with text fields is not text – it is fonts. Everyone has been dying, and I mean dying over this issue for well, in my case a decade.

    Adobe needs to implement an online font system (like google) which makes font loading redundant for any connected app (think about the current flex framework) this needs to look to the local drives for the font then the Adobe server or local (server) file system for the font and then consider some other option.

    Font selection, loading embedding should not even be a consideration, simply select fonts you want – by ID not by name (think of a duey decimal system) – sorted.

    Fonts – not text.

    Thursday, May 5, 2011 at 2:39 pm #
  86. For either a new low level FTETextField, or the existing AS3 based TLFTextField you need more complete HTML and CSS support.

    Especially need support for SEO tags (H1-6, strong, em, etc.), tables, and even HTML5 tags (I see list elements were added in 2.0 – that’s a start).

    It doesn’t need to browser level rendering – converting to TLF conventions to render is fine, but it needs to at least retain proper CSS/HTML formatting and SEO meta information (instead of replacing everything with tags as the current TextLayoutEditor does), and instead retain whatever tag info you put in there. Even better if it understands the tags a bit better – but if the only improvement in TLFTextField (as it exists in Source Forge’s current samples.zip for TLF 2.0) is a better HTML serializer and parser, you’d be golden.

    I’d take a page out of HTML5′s book, and treat whatever tags aren’t recognized as div tags until proper rendering support is added (you can store the original or intended tag name in the “typeName” property like you do for “td” elements). The addition of a “legacy” or “SEO” panel or something cute like that to add HTML tag meta info through a the TextLayoutEditor GUI would be great too. :-)

    Friday, May 6, 2011 at 1:00 am #
  87. Josh wrote:


    thanks for the post this sounds like an ideal solution for us.
    We have gone down the TLF path, using the Adobe hosted RSL (no small task in itself in a FB AS3 project)to alleviate our bandwidth, but it is still a large download for the user when they first encounter it. We probably use 10% of the functionality of TLF in order to get a few necessary features that we can’t make work in TextFields.
    Here is a list of some of the important functionality that we use:

    1) Either very fast re-composition when deleting and adding text to any part of a TextField – And|Or the ability to select across multiple TextFields (or at least easily extend the class such that we can).

    2) Precise control over image floats.

    3) The text selection in the TextField – always reveals the text – even if the text is the same color as the BG. In TLF – the text selection colors and filters can be changed, but the same filter applies to the text and the bg – so white on white text will remain unreadable – even if it is selected. We would like the best of both worlds – be able specify the color of the highlight and the filters on both the text and the BG – such that both are readable.

    We would be more than happy to discuss our usage of TLF and TextFields on a site that gets large usage on both PC and mobile.

    Wednesday, May 18, 2011 at 3:07 am #
  88. Raph wrote:

    Please save our poor little asses and make the rtl work together with css and embedfonts.
    RTL + Loaded fonts + CSS = no go. That’s the biggest problem I have today with flash. I had to plainly explain my boss that I won’t be able to support rtl languages because of the inconsistency between textfield API and TLF. TLF is full of promises but that’s it, it won’t fit as a overall solution for sérious projects. ;-)
    Also it would be nice to have a correct way to enumerate fonts on a loaded swf because I use only external loaded fonts and I had to come up with a naming convention to be able to add them to the main domain. By the way what is this class name / font name problem guys. Wouldn’t it be simpler to keep the same name? Also why creating 3 fonts classes for one family?

    Wednesday, June 22, 2011 at 12:17 am #
  89. I think TLF couldn’t solve the flash problem with text… and there are some other issues that we still have like supporting less HTML tags, etc…

    Text can do a lot of things in flash and change its world, we use it almost every where.

    the news that I have here is to introduce TextArea (NOT the typical Adobe component), it’s a brand new OOP class which is an extension to the Adobe TextField class. you may have not heard about it yet, so thought to share it with you guys.

    Check out http://doitflash.com/ for more information.

    It has lots of new features that help us a lot on our AS3 projects.

    It can support so many HTML tags even our own tags to load MovieClips and SWF files in line of the TextField; also you have much more control over your Text blocks and its contents… such as calling your custom functions right from your text and passing multiple and different arguments through them; loading talking avatars, video players, buttons, slideshows and more… by calling their own tags and having full interaction between all of the loaded SWF modules and your text block.

    the site provides the platform and downloading it is also free of charge :)

    Wednesday, November 9, 2011 at 6:14 pm #
  90. What is the status on this?


    Wednesday, February 15, 2012 at 12:06 am #
  91. rrr wrote:

    I guess it’s safe to say that this is completely dead in the water, along with Flash as a whole now. Yet more half-baked code.

    Saturday, March 3, 2012 at 1:32 am #
  92. Flash is more alive than ever. It is dead for whoever made useless banners and websites. As an application developement platform it is very healthy. I am working more than ever.

    Thursday, September 6, 2012 at 4:17 pm #
  93. The big interest, the huge interest of TLFTextfield is to import file from Indesign. That is very useful !! But there are lot of bug and memory leak. exemple : http://forums.adobe.com/message/4630557

    So please, do not give up the development of the framework TLF !!!

    Thursday, October 18, 2012 at 10:21 am #
  94. Aaron wrote:

    I know this post is 3 years old but I come back to it again and again. How I wish we had a basic FTE based TextField replacement. I never once used TLF in all these years (and I’m glad I didn’t, now that it’s abandoned) but I wish I could use the improved FTE rendering and other FTE features.

    In short, I think Thibault was right all this time and TLF was a big waste.

    Will we ever see this happen? I still hope so!

    Wednesday, May 21, 2014 at 9:41 pm #

Trackbacks/Pingbacks (4)

  1. [...] New TextField API? Dude, we have larger problems. Mobile performance, lack of threads, JSON still not native in the Flash Player, and a long list of JIRA bugs & smaller feature requests people have been voraciously voting on. In my consulting, I’ve seen some amazing TLF usage. That has been the exception to the rule; the forcing it down people’s throats via the broken implementation in Flash CS5, and the god awful horror it is when attempting to embed fonts in Flex 4.x SDK doesn’t get me very excited in “creating a happy medium”. [...]

  2. Difference between TextField and TextBloc (or TextLine) on Tuesday, June 7, 2011 at 2:10 pm

    [...] what now? Should we all start using TextBloc? I don’t know and to be frank it seems like even Adobe doesn’t know. But if you want better looking text, maybe you should. [...]

  3. [...] what now? Should we all start using TextBloc? I don’t know and to be frank it seems like even Adobe doesn’t know. But if you want better looking text, maybe you should. [...]

  4. [...] ByteArray‘da çıkan bir habere göre Adobe FTE ve TLF dışında ve bu ikisinin -komplikasyon anlamında- ortasını bulacak yeni bir [...]