Today I’m very proud to announce the official public beta release of tinytlf [tiny tee-el-eff], a new ActionScript 3.0 text layout framework I’ve been working on. I’m pushing it out as beta v.0.5, with 1.0 due out near the end of September.
Adobe’s TLF and tinytlf
Tinytlf isn’t affiliated in any way with Adobe’s TLF. Adobe has their project and I have mine. Tinytlf is not an add-on to Adobe’s TLF, it has no dependencies on Adobe’s TLF, and I haven’t recycled any TLF code. Tinytlf is a different effort than Adobe’s TLF.
Why?
If the TLF already exists, why create another rich-text framework? Because tinytlf represents a fundamental departure from the design concepts that drove Adobe’s TLF. Tinytlf has no dedicated model. Tinytlf doesn’t define the interactions, decorations, layouts, or styles in the framework code, tinytlf expects external definitions of what a “Text Field” is.
How does a TextField draw underlines or background colors? How does a TextField manage mouse and keyboard interaction? Instead of answering these questions in the core framework, tinytlf instead says: “here, you can draw decorations,” and “hey, you can interact with text, so how do you want to do it?”
Extreme modularity, everything is exposed and/or expected to be defined externally. Tinytlf has an interface specifically for external configuration. Take a look at the configuration for the default TextField component. Everything, from how to parse and interpret data, to which classes render text decorations, to the user gestures and behaviors that govern interaction, is mapped externally.
Tinytlf is 5 individual projects: utils, core, gestures, extensions, and components, respectively. Each adds new features and builds on top of the previous projects. It is explicitly structured with pay-as-you-go modularity. The core framework is tiny: 36kb. Including components, the whole project is 135kb.
Features
Here’s a quick list of features from the framework so far:
- Standards compliant XHTML, including inline and some block-level styles.
- Real CSS stylesheets: style inheritance, pseudo-classes, and cascading.
- A completely configurable decoration engine for drawing shapes in with text.
- A two pronged approach to interaction: inclusion of a powerful gestures API, but also the ability to keep interaction contextual to FTE
ContentElements. - Complex text layouts, including text flow between
DisplayObjectContainers. - Unordered and ordered lists.
- Did I mention CSS pseudo-classes?
- Hooking into the FTE’s performance enhancing techniques, such as only re-rendering invalid TextLines.
- The speed you expect from a TextField, the power you expect from a Text Engine.
…and so much more.
Demos
Fork it on github!
From Here?
Tinytlf still has a long way to go. In the next few days and weeks leading up to my 360|Flex D.C. session, I’m going to be putting more documentation on the github wiki. I have a lengthy “Deep Dive” article that I’m editing and will post soon, as well as break up for entry into the wiki. I am aiming for a 1.0 launch at 360|Flex D.C. As always, feel free to email me with any questions, feature requests, or general feedback. Thanks!
Tags: Flash Text Engine, tinytlf
Yay! Looking excellent!
I am looking forward to see how you will add the support for text editing operations via common Flash keyboard shortcuts (Ctrl+C, Ctrl+V).
Would be interesting to compare the features of your current implementation to “tlfx” (Text Layout Framework Extended project) project
http://code.google.com/p/tlfx/
I have not use “tlfx” yet, but looks like they are going to support rendering of HTML tag in FTE.
Tinytlf has a full gestures library. Very similar to iPhone or Android gestures models. It is incredibly robust. Here’s a quick explanation: gestures are a grouping of events that happened in a determined order. They’re basically just tiny re-entrant state-machines that evaluate when a new event happens. Once the events have happened in the proper order, that gesture is “unlocked,” and fires to all its Behaviors. Behaviors are supposed to be little controller classes which encapsulate one definite action: tinytlf has a “SetFocus” behavior, an “IBeam” behavior, etc. The focus behavior simply sets the stage focus to the object that the mouse clicked on. IBeam just changes the cursor to and from an IBeam. Multiple behaviors can be mapped to the same gesture, and the same behavior can be mapped to run when different gestures fire.
As an example, rapidly click twice or three times on a text line, without releasing the final click, then move around. For two clicks, you’ll notice tinytlf switches to selecting by word, and for three, by line. Those are two gestures I wrote: MouseDoubleDown and MouseTripleDown gestures. It’s not a double-click, which is down-up-down-up. DoubleDown is down-up-down. For single click, there’s a “SelectByCharacter” behavior, which selects text by an individual character (duh). For DoubleDown, there’s a “SelectByWord” behavior, and for TripleDown there’s a “SelectByLine” behavior (which actually changes to a “SelectByParagraph if you turn editable off). You could map the “SelectByLine” to the DoubleDown, and “SelectByWord” to TripleDown if you wish, but they are the way they are because native apps behave that way. I want interaction in tinytlf to be exactly the same as interaction on the native platform.
The only reason there aren’t more gestures/behaviors right now is because there are a ton of them. It’s a ton of work. But believe me, I’m working on it.
BTW, on Windows/Linux, if you hold shift+ctrl and press arrow left/right, it selects by word. On Mac, you press alt instead of ctrl (where the Flash Player instead maps the cmd key to ctrl instead). The devil is in the details!
Thanks for a long wrap-up on user gestures.
I like possibility to specify custom gestures for text selection and I would expect that power users would love it!
RightArrowCtrlGesture, LeftArrowCtrlGesture – no doubt both of those text selection user gestures via keyboard are useful.
Now, it is time to copy the text to the clipboard, looking forward to it!
Do you plan to release tinytlf 0.5 release packaged as single SWC library file or you would rather like the developers to compile the library by themselves via included Ant script?
I don’t typically check in binary files to git. When I get to a 1.0 I’ll have official downloads, packages, etc, but till then I figure the people who’d likely use it are smart enough to know what to do w/ an ant task, or at least load the projects into FB and compile the source there.
Cool, was just about to ask the same question = )
VERY cool stuff!
Thanks!
Fantastic stuff. I am glad you have considered gestures. It will be interesting to see this working on Android2.2
This is really cool. I did a little experiment with tlf text to print ready pdfs. http://bit.ly/9rLD3a I look forward to giving your framework a try and seeing what I can come up with
Hey Paul
Fancy stuff – although I only was able to have a short look so far. What I’m most concerned is speed. You write:
“The speed you expect from a TextField, the power you expect from a Text Engine.”
and that sounds most promising. Unfortunately when creating a simple Hello world speed test (just creating 10000 textfields, adding some text) I see a *massive* decrease (>100x) in speed compared to the bad old flash.text.TextField. Can you elaborate a bit more where speed comes in? (or what I should do different?)
The other thing is size: This simple test mentioned before is (release built) 66kb. That’s not nothing. So may be it just packs a load of features in it, just in case – that’s probably reasonable, but I’ve got to say, that adding this to an existing framework can have quite an impact. I just wonder: why does it have to be that fad? Or rather: can I prevent it from becoming fad?
While digging deeper into ur code, the last question might become obsolete, but for the speed, i’d really love to hear your thoughts and experiences. Thanks a lot!
Sev,
Great points. I’ve spent a large amount of time on new features, while still focusing on keeping the framework modular. There are some optimizations you can make at the FTE level whenever you need performance like you’re describing, and I’ve tried to keep those exposed in the framework.
Unfortunately I haven’t focused on keeping the components very modular. As it stands right now, the components pull from every project that makes up the framework, so you’re absolutely right. I’m trying to get everything in the framework up to a certain level of quality, then I plan on building out the components for better general use. But I’m only one guy ;).
I generally agree with this: make it work, then make it elegant, then make it fast. I think I’m somewhere between step two and three.
Thanks for the interest, would love to get feedback on what documentation or features you need, and maybe even some github pull requests :).
:,; that seems to be a great topic, i really love it ~.`
Hi Paul, Do you have any imminent plans to support tables? Also, is this editor able to support both absolute and relational positions? Thanks!