13 Replies Latest reply on Jun 4, 2013 12:11 PM by James22s22

    How are we supposed to use the TLF at all?

    James22s22 Level 1

      The Text Layout Framework (TLF) is unusable in its current state as of Flash CS6 thanks to its terrible (pre)loading architecture, particularly this issue with ridiculous workarounds such as SafeLoader and ProLoader (http://helpx.adobe.com/flash/kb/loading-child-swfs-tlf-content.html).

      First of all, such a core feature that replaces classic text fields should have been an intrinsic library for the Flash Player, not a separately downloaded RSL.  The decision to make it an RSL has caused no end of headaches and confusion.



      So in that article I linked to (from 2010), it suggested I use a SafeLoader class, that was not included in Flash, which we were expected to either find and download or code on our own, given we were aware of this pre-loader wrapping of the entire SWF in the first place.  Fast fowarding to 2013, I see there is now a "fl.display.ProLoader" class that is apparently meant to be used with child SWFs that use TLF (again, a ridiculous work around), but if you notice its documentation is non-existent. Oh, there’s a page for it (http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/fl/display/ProLoader.ht ml) but notice how the class extends Sprite, and yet it only contains inherited public properties and methods. It lists no methods or properties of its own. There is no load method or content property listed, etc. Nothing. Useless. As a result, TLF is still unusable.  The ProLoader is now a workaround to the SafeLoader workaround.

      Now I'm reading about a problem with embedded fonts in child SWFs that use the TLF: http://forums.adobe.com/message/3826931#3826931

      How can we possibly be expected to use the TLF with these kinds of major architectual and reliability problems persisting in Flash CS6?


        • 1. Re: How are we supposed to use the TLF at all?
          kglad Adobe Community Professional & MVP

          don't use tlf text.

          • 2. Re: How are we supposed to use the TLF at all?
            James22s22 Level 1

            ^this, lol

            as if I had a choice.  the problem is we can't use tlf text, b/c it doesn't work.

            • 3. Re: How are we supposed to use the TLF at all?
              kglad Adobe Community Professional & MVP

              what are you doing that requires tlf text?

              • 4. Re: How are we supposed to use the TLF at all?
                James22s22 Level 1

                I'm just trying to underline a few words in a dynamic text field in the designer.  The text is dynamic and will be altered at run-time, but aside from assigning the entire text fields' value as HTML in the script, there is no way to include underlined words without using TLFTextField.


                This is for a PSSA test that's going to be given to thousands of students across PA and TX, and laying it out in the designer is necessary for our workflow, because we have people who aren't programmers doing this.  That's why we shelled out the cash for Flash instead of doing everything in AS3 with flex compiler.


                It's like... Adobe, how would you feel if someone sold you a car with four wheels, but as you're driving it home one of the wheels locked up solid.  The seller's response is "well then don't drive on that wheel", but alas, in the car's glove box, you find the user manual, where you're surprised to find the solution to your very problem: "just remove the hub cap and bolt a separate steel extension called the SafeRoller  ProRoller on the rear wheel and attach a spare tire to it (SafeRoller not included, ProRoller included only in 2014 models, not recommended for highway use, instructions not included but ProRoller mirrors the way the original wheel worked).  Oh, why didn't I think of that.  I just won't use the feature and then I won't have a problem anymore.

                • 5. Re: How are we supposed to use the TLF at all?
                  James22s22 Level 1

                  At first I thought I might just add the html tags in the text, then set "TextField.htmlText = TextField.text" to apply it, but the extra characters would alter the layout in the designer (number of lines, etc.), and it would require me to include tags for everything else as well (bold, italics, coloring, etc.).


                  What I may do is have the designers set text they want underlined to some reserved color like red (#ff0000) which wouldn't affect the layout, then implement a function that processes the TextRuns and converts all red text to underline via setTextFormat(range).  I'd rather just be able to click an underline button in classic text set to render as html.

                  • 6. Re: How are we supposed to use the TLF at all?
                    kglad Adobe Community Professional & MVP

                    you can just assign a textformat to your text that needs to be underlined: use underlineF by passing the textfield, its string and the string you want underlined.  it can be called repleatedly to underline different parts of the string.  if multiple instances of the substring to be underlined are in the text, the function will need to be amended.


                    function underlineF(tf:TextField,s:String,uS:String):void{

                        var tfor:TextFormat = new TextFormat();

                        tfor.underline = true;



                    • 7. Re: How are we supposed to use the TLF at all?
                      James22s22 Level 1

                      That's not a solution to the problem.  The problem is that text can't be underlined in the designer.


                      I already wrote a TextEffects class that includes all kinds of methods like selecting a TextField, finding a word and flashing it, finding the next or Nth occurrance of the word, finish flashing, finish flashing and leave highlighted, type out animated text, set a particular word (range of characters) to flash while being typed before they are even typed out, break down an entire text field into individually clickable words that accepts an array to group certain phrases as a single clickable object, etc.  I know how to format a TextField.  I've subclassed TextField to fix a lot of bugs with it regarding how it treats trailing line breaks at the end of a paragraph due to it's internal HTML representation.  I'm very very familiar with TextField and all its features, limitations, and bugs.


                      The problem is that Flash doesn't include an underline in the designer, so I can't underline text in the designer view.  TLF can do it, but TLF is broken.


                      Specifically, I've narrowed it down to the situation that in a loaded child swf, if the TLFTextField has an instance name beyone frame 1, then it won't show up at all.  If I remove the instance name, then it shows up.  The problem occurs only when the swf is loaded at runtime with Loader or ProLoader, and it seems like the object instance exists, but the text isn't set by the keyframe.

                      • 8. Re: How are we supposed to use the TLF at all?
                        kglad Adobe Community Professional & MVP

                        if you want to underline static text in the ide, use the pencil or pen tool.

                        • 9. Re: How are we supposed to use the TLF at all?
                          James22s22 Level 1

                          I managed to get the text to show up by supplying a LoaderContext instance to the ProLoader's load method, and explicitly specify that I want it loaded into the current application domain with ApplicationDomain.currentDomain.


                          The text shows up now, but there's still a problem with it.  The text appears to be displayed with a standard times new roman font UNTIL I CLICK IT, then it switches to using the embedded Arial font that was assigned to it.  This occurs for both selectable and editable TLFTextFields.  If set to read only, it's worse, because it is stuck with the times new roman fault and clicking it does not correct the problem.


                          There's obviously major issues with the TLF.  The fact that when I don't specify the current application domain as the target, fields assigned instance names don't show up, while ones that aren't assigned a name show up fine.  Meanwhile, if I do specify an application domain, then the font isn't applied correctly initially, but if the field happens to be selectable or editable, then attempting to interact with the field will cause it to proptly update to the correct font.  Rediculous.

                          • 10. Re: How are we supposed to use the TLF at all?
                            James22s22 Level 1

                            Pencil or pen tool is no better than actually worse than just assigning the underline in code.   As I said, it's not static text and I have code that breaks down a text field into individually clickable words, and so all the formatting info for the text must be specified by the designer on the text field itself, not as some unrelated stroke that happens to line up with the text where it happens to be located at compile time.  If the text wraps differently (it's usually a pixel-perfect overlay thanks to the updated TextMetrics system in AS3, prior to which I was manually parsing AFM (Adobe Font Metrics) files myself and writing my own line breaking algorithms to get it all to line up with the original text), or certain words are replaced dynamically at runtime, for example to show students a correction, then the underline will become misaligned.


                            It's frankly mindboggling that in over a decade Flash has never added the ability to do something as basic as underlining text in the designer.

                            • 11. Re: How are we supposed to use the TLF at all?
                              James22s22 Level 1

                              Ok, I further tracked down this bug to being some kind of initialization problem, and this is the exact configuration necessary to fix it (but there are still more serious issues like fonts not being correct), otherwise all of the bugs appear.


                              In my main application, I link the text layout framework as "merged into code".  This makes the framework classes available in the main application, so that loaded child SWF files don't have to embed it.  For child SWFs, I set the text layout framework linkage to "external library".  That allows it to compile without embedding the framework, and while the child SWF won't run on it's own (it's not designed to), the external linkage allows it to find the classes it needs that were embedded in the main application.  That much I've done from the very beginning, so this is all nothing special, and all the mentioned bugs have occurred with this set up.  Now, for the fixes:


                              To get the TLFTextFields with instance names to actually show up, when calling ProLoader.load, I must specify that I want the child SWF loaded into the application domain of the caller using a LoaderContext instance.  This ensures it uses the existing, already-initialized classes of the TLF in the main application SWF.  So far, this gets the text to show up, but they're initialized with the wrong font until you click them (if they are selectable, otherwise they're stuck that way with the wrong font).


                              Finally, to avoid the aforementioned font initialization problem I saw in child SWFs, I had to made sure I added at least one instance of a blank TLFTextField to the stage of the main application.  This will be removed programatically at runtime, but it's initial presence on the stage seems to have performed some kind of initialization of the TLF that corrected the issue with the child SWF.  If I remove this dummy instance in the main application, the problem returns in the child.swf, so it's definitely initializing something.


                              UPDATE: The fonts are still wrong.  Although it seems to load an Arial font, it doesn't match what I see in the IDE.  It's a little too bold, but it's not Arial Bold, so I suspect it's using the Arial (bold) font that's embedded in the main application (rather than the one embedded in the child.swf), and those are using the DF3 outlines rather than the DF4 outlines.  So by loading it into the same application domain, it fixes one problems but creates another.  So still, the TLF is not viable.


                              The other major problem is that since TLFTextField is not a TextField, any complex libraries designed to function with TextField will not work, since it uses a completely different API.

                              • 12. Re: How are we supposed to use the TLF at all?
                                James22s22 Level 1

                                Here is a screenshot of the differences I see at design time vs runtime.  Both fields started out as TLF, then I copied them and set them to Classic to see how they differ.  Each instance is aligned to whole pixel values for x and y, and the design time preview mode is "full".  Runtime rendering quality is "high".TLFInconsistencies.png

                                Notice how in the designer, the TLF text looks very different than it does at runtime.  It's longer and less bold.

                                At runtime, the Classic text field look basically identical to how they look in the designer.  The classic text fields even render better... notice how the "i" in the word "aligns" has the dot distinctly visible, whereas the TLF text the dot is not cleanly separated.  Layout-wise, the TLF text is rendering a lot like the classic text at runtime.  How am I supposed to use TLF text with these kind of bad inconsistent results?


                                If you overlay the runtime and designer versions of the above screenshot, the classic text aligns pixel perfect with the designer, while the TLF text is drastically different in font thickness and text width.

                                • 13. Re: How are we supposed to use the TLF at all?
                                  James22s22 Level 1

                                  Reading more about TLF text, I don't understand how this is an improvement when it lists points like this:


                                  • TLF text cannot be used as a layer mask at author-time. To create a mask with text, create the mask with ActionScript 3.0 or use Classic text for the mask. See Masking display objects in the ActionScript 3.0 Developer’s Guide.
                                  • Anti-aliasing settings for TLF text are not reflected on the Stage until the Flash file is exported as a SWF file. To see the effect of anti-aliasing settings, use the Control > Test Movie > Test command or the File > Publish command.


                                  That's just wonderful.  It's nice that when I edit TLF text on the stage it lines up exactly whether in edit mode or not, but then the real killer is that it doesn't line up at all with how it looks at runtime, which is actually worse than classic text, which shifts a bit while editing it, but once you exit edit mode, it looks the same at runtime.  Then to suggest that we should just "publish the movie" to see what it looks like... that doesn't work, because if I'm working on a particular frame of a child movie with external reference's which is part of a larger application, then I have to publish the main swf, ensure connectivity, log in, and then navigate to that particular resource to view it.  The designer is supposed to reflect or at least approximate what I'll see at runtime, but with TLF text this isn't the case.