I’ve been thinking a lot about TLF over the past few months; not just about how to use it, what features I like, or what bugs I’ve encountered, but about the philosophy and underlying model it’s built on. I’m hoping that by sharing these thoughts and getting input from the community, I can provide useful feedback to Adobe both about TLF and their future efforts.
I’m sure I’m oversimplifying in some places, and completely wrong in others. Please excuse any errors.
Background
Flash Player 10 introduced the flash.text.engine.* (FTE) package, which contains classes that provide low-level text handling capabilities. FTE is extended by a set of ActionScript 3 classes in the flashx.textLayout.*, known as the Text Layout Framework (TLF), which is shared between Flex and Flash Pro. These classes provide abstract FTE somewhat, but remain fairly low-level.
Flash Pro exposes TLF through a new TLFTextField component, which provides IDE integration and a high-level AS3 abstraction that closely mirrors the TextField API, but with a broad range of new text and typography features. These include multi-column text, text threads (aka linked fields), right to left and vertical text, and a host of typographical enhancements.
The Flex 4 framework exposes TLF through 3 primitives: Label, RichText, and RichEditableText. These provide increasing levels of capability. Label displays a single line of text with a subset of formatting options. RichText supports multiline text with inline graphics and full formatting. RichEditableText adds links, editing, scrolling, and selection. Flex does not have support for text threads.
Philosophy
TLF illustrates a philosophical shift in API development for Adobe. With TLF Adobe chose to expose only a very low-level player API, then build a “standardized” higher-level AS3 API on top. The reasoning behind this appears to be to reduce player size, and facilitate development of the TLF libraries without a dependency on player updates. This means developers can utilize new TLF features as they are released without having to wait on a new version of player to achieve acceptable penetration.
The intent is good, but I’m not convinced it is the best approach in this case. With virtually no exceptions, text is a core element of every project built on the Flash platform. Making core text capabilities dependent on an ActionScript library introduces a variety of issues that I personally feel outweigh the advantages listed above.
File size
The core TLF library weighs in at about 160kb. This is exported as a signed RSL (.swz) beside your SWF. This means that once a user downloads the .swz for a specific version of TLF once, it should be cached locally and reused whenever the library is subsequently used, including on other domains.
This is nice, but if TLF is the future of text in Flash, and text is core to all experiences, it invalidates any benefit to player size. If all users will need to download the RSL anyway, you’re just distributing the problem. I’m also under the (perhaps mistaken) impression that the functionality would be smaller if implemented natively in the player.
Even with the RSL, using a TLFTextField in Flash Pro introduces an additional 60kb to your SWF. This is a pretty big hit for just putting hello world on the stage, and makes TLF unusable for banners and other experiences with file size restrictions. Exacerbating this, Flash exposes TLF as just another text option, not as a component, which makes its cost unclear.
Performance
Because TLF is implemented in ActionScript, it suffers from the same performance problems and memory issues as other AS3 code. Performance in AS is magnitudes better than it used to be and 10.1 brought significant improvements to memory use. However, AS performance remains *much* slower than native code (10-100x in many cases), and memory use is still much higher.
TLF suffers greatly from this. It uses far more CPU to manipulate and display text than TextField, to the extent that Adobe has recommended not using it for mobile devices, and is considering development of a light-weight implementation of TLF specifically for devices. I find it disappointing, and a little ironic, that two of the most important new initiatives for the Flash platform, developed in parallel, are incompatible.
TLF also consumes much larger amounts of memory than TextField. Beyond the memory cost of the AS framework itself, it has to generate huge AS object models describing text structure and layout. It also generates large numbers of display objects (TextLine) to display the text.
This is made even worse by the fact that in TLF all of these objects are generated and maintained for all text in a scrolling text region, not just the visible text. While only the visible text is rendered to screen, there is still a display cost for every TextLine instance as it has to be iterated and culled from the scroll rect. This means there is a high cost for both memory and performance associated with large amounts of text in a scrolling text area. In TextField, this cost is very low.
Flash performance is already a hot enough topic. TLF’s AS implementation is going to make it worse.
Consistency & Complexity
TLF represents the first major collaboration between the Flash Pro and Flex teams. This collaboration is a *great* thing!! I cannot emphasize this enough. These teams really need to work together to create a unified component framework and integrated authoring platform, and I hope that TLF provided an opportunity to really test these waters. Unfortunately, I don’t think they went far enough.
Right now, Flash Pro has a very decent high level abstraction of TLF with TLFTextField. It exposes an almost identical interface to TextField with a lot of nice additions. It’s easy to work with, and simple to extend.
Flex, regrettably, does not appear to have any similar high-level text control built on TLF. Even TextArea lacks most of the functionality of a TextField. To achieve even very simple tasks like finding the position of a character, you are forced to wade through the TLF library, and dabble in FTE.
At this point, I am concerned it will be difficult to retrofit these capabilities into Flex’s spark architecture. I also wonder if these features are missing because of their performance implications when implemented in AS.
Versioning
I understand the benefit of being able to version TLF separately from the player, but leveraging it introduces another set of problems. Firstly, it reduces the efficacy of the cached RSL – it has to be downloaded and cached for every new version. It also has obvious implications for team development, custom controls, and commercial or OSS libraries / components that target TLF. None of these are huge issues (except perhaps the last one), but they still reduce the overall benefit of the model.
Thoughts
As someone who has messed around pretty deeply with the TextField APIs, trying to force it to do some of the things that are possible with FTE (multi-column, decorations, etc), I appreciate the inclusion of low level text APIs. However, I think text is too integral to interactive media to not make usable and performant APIs a core part of the platform.
What I would really like to have seen, was the same low-level FTE API, extended with a player level API for text layout similar to TLF. This could be built on a set of interfaces (as it already largely is) to make it easy to write alternate AS3 implementations of these classes. Further, I would have liked to see a usable text field implemented at the player level on top of these APIs, with most of the functionality of TLFTextField. It would expose an ITextField interface which TextField would also be retrofitted to support.
Ideally, this would provide greatly enhanced performance and reduced memory footprint, while still enabling developers to dig deeply and create custom implementations. It would guarantee a consistent API and implementation between Flash and Flex and even allow developers to work with many aspects of text without knowing if the container is TLF or a TextField by typing as ITextField. While it would increase player size, it would reduce the overall bandwidth spent on downloading TLF related elements. Adobe could even update some aspects of TLF between player versions by providing AS3 extensions of the built in classes.
It may be too late to do this, but I don’t think so. The current player APIs would not have to be changed, which means current content wouldn’t break. The current TLF APIs and a TLFTextField equivalent could be implemented natively in the flash.* package, without breaking the current AS3 versions. A future version of the Flex framework could migrate to use the native API with minimal disruption. Likewise, Flash Pro’s TLFTextField could be stripped down, and become viable for banners and mobile.
If this can’t be done, I’d like to at least see some engineering time spent fixing and enhancing TextField, so that we can continue using that when TLF simply isn’t the best choice.
Even if it is too late to fix (in my opinion) TLF, I think it’s important to raise discussion around Adobe’s new philosophy to help steer future decisions. I don’t think Adobe should go as far as MS has with Silverlight, where controls/components are embedded in the player, but I do think that elements that are as core as TLF belong in the player.
There’s a lot more I’d like to say, but this is getting long, and I think it covers the most pressing topics. I’d love to hear what you think in the comments.
Agreed, I was disappointed with TLF as soon as I dragged an instance of it to the stage just to mess around with. Even more when I saw that CS5 calls the non-TLF text “Classic” as if they had created its ideal replacement. Thanks for sharing your thoughts.
Excellent post as always! I am watching this whole TextField,FTE and TLF thing from the beginning on and I am still not very happy with the way it is implemented.
The biggest problem in my opinion is as you also stated performance. Even if implemented with the native FTE support, rendering a simple text is A LOT slower than with the good old TextField.
Of course, it has also a bunch of very nice new features, but as TextField only supports the fonts embedded without CFF you can decide in your project to stick to the old TextField to keep performance up or take the better looking CFF fonts and use an FTE implementation.
Regards
Matthias
Quick note: Flex’s spark Label does allow multiline text, see maxDisplayedLines property.
I have to say I agree with most of your points, I never really understood and appreciated the .swz thing…
I’ve also been surprised to see the htmlText property didn’t evolve much: you still can’t use “sub” and “sup” tags but you can somewhat emulate them with the baselineShift attribute.
Having just finished reviewing a book for beginners, I’d like to add that while the TLF integration into Flash Pro is great, it being not part of the player makes publishing overly complicated.
There are rather complex technical details a new user or non-technical user has to learn now that they shouldn’t have to.
Back when 10.0 had just come out with FTE and the first betas of TLF were released, I went through both of the APIs to determine which would be best for my project. I had to support right-to-left and left-to-right text, ligatures for Arabic, configurable hover events for individual words, and the ability to draw boxes around a configurable block of text on hover. The first two items were supported by TLF, but the last two were most definitely not. I ended up, after about a week of testing and tweaking, with a 180 line base class that gave me all this functionality through the FTE APIs.
On the other hand, I have my experiences with the TLF integration into Flex 4, and although I’m only using a portion of the TLF APIs through the spark components – just Label and RichText, I’ve been quite pleased with it all.
So, if I could get native support for text rendering using the new TLF markup format, I would be supremely pleased, but I’m not particularly hurt by the fact that it’s implemented in AS3 and not in native code.
I am 100% with you. The last two years or so I have been (on and off) busy with building both a TLF alternative engine as extending TLF 1.0. On various occasions I expressed my concerns to the TLF team too about the size, the performance and implementation.
I think your thoughts are spot on and I would like to see the very same thing to happen for Flash 11.
While trying to extend TLF I was very disappointed to see that much off the classes I needed to extend where final or contained protected code that was difficult to extend due to internal dependencies on private code. In the end I had to add an awful lot of otherwise unnecessary code. When it became clear that TLF wasn’t fit for deployment on new generation Flash 10.1 enabled smart phones the project was abandoned.
Another thing I am disappointed about is that TLF is very much targeted at a DTP like implementation. I would rather liked TLF to be a more general framework that would leave it up to us to extend it into for example a HTML/CSS renderer/editor or a DTP like engine or whatever.
When the FTE and TLF first came out, Paul Robertson from Adobe wrote the following article about the future of ActionScript, about how Adobe could/should release new Player functionality in very low-level APIs, with high-level APIs created in AS3:
http://probertson.com/articles/2007/10/15/future-actionscript-apis-high-level-or-low-level/
The idea that this leaves the door open to any 3rd party in creating their own library that the Flash community would not be stuck with whatever they came up with.
Also I think one of the definite benefits is that with so much code to make the TLF work, there’s lot of bugs and updates needed. When TLF was first released there were a lot of changes made in the nightly builds. If this was a native API, there would have been changes each Flash Player update. Or progress could have been slowed down for bigger updates for each major Flash Player update. Meanwhile, as an open source project, the Flash community can debug and submit patches. Rather than it be a native API, where workarounds would have to be implemented around any bugs that popped up and little input from the community can be given with any such problems.
Of course, the FTE in Flash Player 10 & TLF was released in beta in 2007, the same year the first iPhone was released, when smartphones had just started to evolve in what they are today. Quite likely the planning and development that went into FTE & TLF pre-dated the iPhone and so the focus was how they would preform on desktops.
That said more could be done in optimizing the TLF. Perhaps a more lightweight version could be devised for when only a small number of features are needed.
Also I have wondered about Adobe doing more to cache frameworks like TLF, Flex and Open Source media framework. Perhaps have check boxes when downloading Flash from Adobe to include the latest version of TLF, Flex and OSMF with mention that it will provide users a faster experience on sites that use these frameworks. Or perhaps have demos on these frameworks on the bottom of the page that loads when a user has successfully downloaded Flash.
I’m pretty disappointed in TLF in Flex. Label, TextInput, and TextArea are EXTREMELY common controls to use in Enterprise applications. There is no easy way to append text to these controls. You can’t right click and copy/paste/select all.
Spark already started off on a shaky foot with it missing a significant amount of comparable components that mx had. That, and a lot of “easy” things became hard for strictly Enterprise developers who don’t focus much on the skinning features that Spark offers.
I like Spark, but I do NOT use any of the Spark text controls in my Flex work.
Regarding your philosophy, I was a little disheartened when Tinic Uro confirmed that as Adobe’s direction of building low-level API’s, and having them or 3rd parties building atop of them. TLF doesn’t fit that model, because as you said, it’s still very low-level and doesn’t really provide high level functionality for what Flash designers need, or what Flex Developers need for quick component modifications. Even if we do, it’s built in AS like you said… for something that already consumes a lot of memory. Add in a lot of FXG, and any chance of running decent on a phone are out.
I fail to see how Hero (formerly known as Slider, now Flex 5’s component set with heavy emphasis on mobile) can address both of the above without having built in player API’s for the reasons you mentioned.
Jesse, you can right click, copy/paste/select all. I just confirmed in a Spark TextArea.
Very good article. I was planning to add TLF to one of my projects but having read this, I have to say, this will be postponed for sure.
Even tough Matthew Fabb brings to light some very important facts into the discussion, it seems to me that Adobe’s reasoning on the topic was greatly overcome by events that followed. The mobile scenario greatly created by the iPhone release and Apple’s decision to force flash out of iOS, brings questions/problems that will have to be addressed.
With or without Apple most of the next decade content will probably be created for mobile consumption. While it may not be solely intended for that platform it will be taking it into consideration for sure. Rules are changing and Adobe will have to adapt.
In my opinion, if TLF cannot be used in the mobile scenario, it will be left out by most developers. One other reason to leave it out, even when not targeting mobile devices, is the fact that, as you’ve said, text is a too integral and core part of most rich applications and the benefits of using TLF don’t seem to outdo the hassle and extra work it brings into the picture.
I do hope Adobe addresses this quickly. I love flash platform but one of my fears when Adobe acquired Macromedia was that the resulting company would less agile and less in touch with the developer community and users needs. Let’s hope I was wrong.
Thanks for this thoughtful feedback (in the post and comments). It’s all quite useful, and the entire TLF team is reading and discussing what’s been brought up here.
Since the TLF 1.1 release we’ve been working on performance and memory improvements, and adding lists and floats. Our hope is that we can get TLF 2.0 to work acceptably on mobile platforms.
This week we’ve put a snapshot of our 2.0 codebase up on a new SourceForge site. We’re working on making the SourceForge repository stay in sync with our daily development. At the moment the code is not ready for real use (lists aren’t completely done, links have some problems) but it should show some of the performance improvements we’ve been able to make, and there are some fixes for bugs our forum users have pointed out.
The site is https://sourceforge.net/adobe/tlf – most of the wiki is out of date, so ignore everything but the code for the moment. We’re working on updating the wiki and publishing blog posts that describe the new features.
First of all, I totally agree the TLF should be integrated into the Flash Player. It feels low-level enough and integral enough to any swf that that’s where it belongs for the reasons you’ve mentioned.
On the other hand, having dealt with TLF I can say it’s extremely difficult to get anything done by just extending TLF classes. I’ve been vocal about this before (see http://forums.adobe.com/thread/646563) and will continue to be because I strongly believe Adobe is crippling the extensibility of their code due to how frequently they employ private members and final classes in their code. It’s nigh unto impossible to do anything useful without modifying the TLF code itself whether it be fixing bugs or customizing functionality. If you feel the same way, I encourage you to visit the link above and let it be known. They are listening.
With that said, it’s convenient to have access to the TLF code so at least we can modify/fix it when needed. I’m afraid if they pushed TLF into the Flash Player in its current form the cases where it could be used successfully would be relatively low. If they truly made their classes extensible (read: protected members and non-final classes) and fixed the plethora of existing bugs I would greatly encourage it being pushed into the player.
Very good points. I gave up using TLF right the first time i publish my .fla
160kb in .swf should be much smaller in native code i believe. So please add it into the player
And again. Thank you. Thank you. Thank you. Thank YOU for doing Flash platform better (dosen’t matter how)
I would like to add a few points.
Regarding download size I think it would help if the download would be partitioned into 3 parts: de TLF renderer, TLF Selection, TLF Edit. In case of a download on a slow (phone) connection you could probably suffice with the TLF render lib only and load the rest only on demand.
With regards to TLF’s final classes and private code, the team on occasion suggested that we could fork the code and make final classes not final and private members protected our selves. This is of course true but that would mean we loose the benefit of the player cache (which can only contain Adobe libs). This would make the download issue even a bigger stumble block.
@Alan, you wrote “Our hope is that we can get TLF 2.0 to work acceptably on mobile platforms”.
It should be EXCELLENT in my book. It’s obvious that with Flash Player 10.1 becoming available on a huge number of mobile devices in the near future we don’t want TLF to become the killjoy. Nowadays it’s already difficult enough to convince bosses and customers to go with the Flash Platform due to the Apple campaign against Flash.
Our customers need BIDI support on their mobile sites and they want those sites to load quickly, not drain their customers battery and have the site perform EXCELLENT.
If excellent is not possible on all Flash 10.1 devices then PLEASE go another route (e.g. the one suggested by Grant).
“I don’t think Adobe should go as far as MS has with Silverlight, where controls/components are embedded in the player”
I do! But I still need to find other people that agree with me:
http://blog.zarate.tv/2009/06/04/adobe-vs-skinning-components/
sounds awesome, but wtf is TLF?
When I upload my SWF that uses the TLFTextField do I need to upload the textLayout_1.0.0.595.swz file as well?
I think most of the problems with the FTE would be solved if they implimented something like a setFontMetricsFormat method nativly that would draw selection boxes, underlines and so on each part of text. Much of the slowness comes out of all of the small shapes and managers of these little things. A square that is few pixels high takes as long to render as a big one and if your text changes all of these shapes are removed from the display list and redrawn.
But it would also be really nice if TLF supported all of the features of TextField. Things like stylesheets are really missed even if basic.
totally agreed! TLF Was a needed step into a powerfull text engine.
But its now time to get community feedback to find what is most important in the API and implement that into flash player.
I think a more fundamental problem is that the range of use cases for this lib is so huge that it’s hard to nail down the right approach. It could be used for an incidental text label in a mobile game or a novel-length document in a desktop reading system. It’s not easy to design a system that works well at all those different scales.
But I agree with Grant that this whole thing would have gone over better if there was a sort of TextField replacement that worked better than the old TextField and was easier to use, and didn’t require the overhead of the TLF. That wouldn’t have been that hard and would make 90% of people happier.
Good HTML/CSS support would also make a big difference.
I agree 100%.
I cant not add anything more on TLF.
Same goes to FXG. As TLF should be part of the player, i think FXG also should be rendered by player. It is really useless at this point if you need to add a huge FXG rendering library just to show a FXG layout on a AS3 only project.
I am really disappointed with Adobe when i heard TLF will be a RSL.
I am hoping someone is reading your great post.
Thank you very much.
Using TLF in banners is generally a no go considering most standard display ad specs still require Flash 8 and below. If TLF or FTE was added to FP11 it would be a while until most of specs caught up.
I haven’t used TLF in great detail but in a general observation I noticed that it was missing some of the features in previous text field styling such as, fontThickness (no need to correct me if i’m wrong here).
Some of the impressions from the people on the team here is that they preferred the rendering in the non-TLF text displays.
Hopefully the mobile player related issues are sorted out.
A massive requirement for TLF indeed.
Adrian – You should update to the flex 4.1 SDK which seems to include quite a few optimizations and memory fixes. With it you should be showing “textLayout_1.1.0.604.swz”. http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4
I have been building a fairly large flex 4 & TLF text based research application and made a very early choice to go with TLF. We are just about nearing our first final release now and I can tell you dealing with TLF has it’s ups and downs. It feels like Adobe was crippled by the idea of wanting to make a low level api, but at the same time provide high level functionality. In the end it just feels like quite a mess, and finding really good examples and tutorials of specific use cases has been nigh impossible. You can beat it into submission to get it to do what you want and how you want to do it, just be prepared for a long battle and lots of time on the TLF forums. I agree completely that we need a much better high level component in flex to work with as well. Overall though, I think it has been an extremely helpful tool.
TLF is probably the most frustrating library i have ever used. I have written a blog entry (http://blog.pixelfarm.nl/?p=423) back when it used to have that component for flash IDE, not much has changed since then. Today i got a chance to work with it again. All i needed to do is add emoticons recognition to a text field (since regular TextField cant render htmlText properly with multiple images…). It ended up as 6 hours of work. TLF is a train wreck and every experience i had with it was followed by pain and frustration. Its time consuming, its poorly documented. Powerful- yes but darn, that’s an overkill, all i wanted as a dev from Adobe, is to fix multiple images issue in htmlText. How many of us actually build something close to times reader?
I’ve been using TLF for some time, some ups and down as with any framework. Most of the problems with it is that the document is poorly documented. I have did a few blog post on some of my findings that may help others:
http://ihaveinternet.com/2010/07/19/textlayoutframework-fun/
http://ihaveinternet.com/2010/06/21/textlayout-framework-and-the-inlinegraphicelement/
I’ve been working on a large project with TLF for the last several months, diving into the source of it and extending it, and share a lot of the same concerns, mostly in terms of performance and file size. One thing to realize is that FTE produces only static/dynamic text. Anything that looks like input text is done in ActionScript in TLF. Selections are drawn with the drawing API. Keyboard input is done with key up and down listeners. Even the text cursor is a sprite set to blink with a timer.
I’ve always been an advocate of Adobe exposing low level APIs and allowing people to build on them in AS, but something as basic as text should be low level.
I’m impressed by what I see Paul doing with TinyTLF, but TLF alone struck me as typical Adobe failure to create some truly elegant, and rushed another feature & product through QA. Shit like this makes me think maybe Flash Player internals would get more TLC if opensourced
What can I say? I just wanted to get started using TLF and while googling for a method to use the new TLF Textfield with a non-FlashIDE project in FDT I came across this post. I’m realizing that TLF is a dead-born child! For small applications it’s overkill and for large projects that process a lot of text it becomes a serious performance consideration. The implementation to load the TLF API as a RSL and not make it a Flash Player native API is a travesty to say the least! It’s a pity really! This looked so promising. I think the only way how Adobe can fix this is by adding TLF as a native API in the next minor updates of Flash Player and AIR asap.
sascha – TLF definitely suffers from some problems that in my opinion make it less than ideal for use in the majority of projects (and completely unusable in many). This is unfortunate, but TLF still does provide a solution for a number of major legacy problems with text in Flash (RtoL, vertical text, highly typographic magazine-style layouts, etc).
Would I like to see it become useful in a more general sense? Of course, but I don’t think the current incarnation ranks as a *travesty*. 🙂
Interesting article! I really think FTE is nice but moving parts such as selection to the player would be a good thing. As long you could override in AS3. But not in such manner how it went with the ‘classic’ text field. You can’t use the input text field anymore if you wanted to change the caret… to fade in/out
I mean making a good editor also toke key up/down listeners, custom drawing of selections and scale of text fields…
Awhile back I built a full-featured text editor in Flash with the TLF with the idea of implementing it in a CMS to handle some special case stuff. I found it to be a pretty frustrating exercise, and although I was successful I had to do some real hackishness to do simple things, like bulleted text and tabs…
I just upgraded to CS5 and had high hopes when I saw the TLF Textbox, so I started messing with it, compiled the file and LittleSnitch lit me up like a bad burrito. Suddenly my file with nothing but a text frame is requesting crossdomain files from Adobe and trying to download a .swz… WT.TL.F?
A can of gas and a match sounds about right. Using it felt like it does when I’m using something I wrote in a hurry and never quite got it right. The idea is great, the results mostly great, but the trip to get there makes it more trouble than it’s worth.
I really wish they would put a little effort into expanding the capabilities of htmlText.
Anyhow, I like the concept, it just isn’t right yet.
Thanks for writing this up, totally agree.
The performance of TLF has to be optimized, and the memory footprint is so high comparing with classic TextField.
I was so surprised why the TLFTextField was not in flash package. This is very useful for most AS3 project, not just within Flash Pro.
I pretty much agree with all that has been said here. Let me add that you cannot build an optimal TLF or a TinyTLF on a bad foundation such as FTE. It’s slow, uses way too much memory, is and poorly implemented.
You can check and vote on this bug report I filed way back when that talks about possible improvements for FTE:
https://bugs.adobe.com/jira/browse/FP-3133
And really, some simple improvements to the existing TextField could go a long way.
TEXT CONTENT… Can you over emphasize how important it is to have an awesome easy to use text system in your application. The fundamental form on communication on the web… Sure the animation stuff is important and sets the flash apart… but when it comes down to it, if you battle to implement your text content due to performance why would you bother putting in all the effort to have a substandard application and unhappy clients.
I think that if adobe took a chill pill on half implementing 3D etc etc… and focused on making their text capabilities powerful, easy to use and with good performance we would see a lot more awesome flash based applications because people wouldn’t feel as though they are wasting their efforts fighting against all the limitations concerning text content…
I think its better to have to wait for the next flash player for upgrades on the TLF than to have a sub standard “flexible” approach now
Hi,First of all thanks to Mr. Grant Skinner (Great person).
There is also a problem with TLF about pasting a text from outside or even if from another TLF or classic (editable) textfield.
For e.g
If a swf file containing TLF is running and if we copy some text from outside (let say a notepad) and paste into a TLF the pasted text font size becomes smaller. I also tried within two TLF but the result is same.
I think there is some problem in TLF’s clipboard data handling. Not sure what’s going on hope for a solution.
Thanks
Rajneesh
I’am totally agree with you. I’am very exciting with Stage 3D, Starling … But First at all we need an native Text API as TLF! A API that we can use into mobile applications.
Thanks Laurent
I am very interested in your thoughts, and will take a closer look at TextField as a result of these comments. But I would like to add that I have had excellent results using TFL on a mobile device, but not when using RichText, and RichTextEditor. Instead, i loaded data and parsed it into strongly typed TFL objects like ParagraphElement. Then I assembled these in a FlowComposer. Pages of text created this way render very fast, and scroll without any hesitation.
This solution is excellent for pages of flowing text, but would be awkward for small pieces of text arranged within layout groups. Based on everyone’s comments, I will give TextField a try.
Thanks much. Gary