I found there is a partial implementation of a TextField back-compatibility class included in the SDK
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/FTETextField.html I'm going to try some experiments to use it from LzTextSprite. I'm not too optimistic because there was a forum post on an adobe board as recently as February that complained that only about 60% of the TextField methods were actually implemented by this, but it may be sufficient for doing basic display and support of bidirectional text, and we do have access to the source code for it. On Sun, Jun 27, 2010 at 7:51 PM, Henry Minsky <[email protected]>wrote: > Hmm OK I am going start making a TextField-compatible wrapper. I agree that > it's too much risk and maintenance headache to try to maintain separate > LzTextSprite implementations. > > Maybe if we release a version, we can get some help from Flash developer > community to maintain it as well. > > > > > > On Sun, Jun 27, 2010 at 2:41 PM, Max Carlson <[email protected]>wrote: > >> Yeah, it definitely sounds like we need to only use the new text fields >> when they're required, e.g. when RTL display is on. They need to have >> feature parity with TextField so having a quirk that turns them on >> everywhere is useful for testing. >> >> I think we could get a lot of momentum behind a wrapper that implements >> the TextField API, and it would reduce the API coverage/risk of maintaining >> two separate LzText/InputtextSprite implementations... >> >> >> On 6/27/10 11:13 AM, Henry Minsky wrote: >> >>> I found a somewhat more efficient way to append arbitrary HTML text to >>> a TextFlow. >>> It's possible to create a new TextFlow for the content you want to >>> append, and then >>> copy it's child 'FlowElement's to the main TextFlow, e.g., >>> >>> public function appendText( t:String ):void { >>> t = t.replace(linebreakPat, '<br/>'); >>> var aflow:TextFlow = TextConverter.importToFlow(t, >>> html ? >>> TextConverter.TEXT_FIELD_HTML_FORMAT : TextConverter.PLAIN_TEXT_FORMAT, >>> config); >>> >>> while (aflow.numChildren) { >>> textFlow.addChild(aflow.getChildAt(0)); >>> } >>> textFlow.flowComposer.updateAllControllers(); >>> } >>> >>> This is a lot faster than regenerating the whole TextFlow, and mostly >>> works, except it always creates a linebreak before the new content. >>> That may be fixable by merging the last SPAN or P or whatever element >>> it is using. It's still seems noticably slower than setting the text >>> in the old TextField though. It takes about one second between clicking >>> on the <canvas> object and seeing the debugger output appear, I'm not >>> sure what the delay is due to. >>> >>> It seems like a step backwards if our text output is slower than the >>> existing >>> TextField object. So it may be that we really do want to keep the >>> existing LzTextSprite >>> implementation and also offer a TLF-based text object as well, when >>> bidirectional text is >>> needed. >>> >>> I guess I had better get some timing measurements on how long it takes >>> to execute >>> a setText and addText for TextField vs the new TLF stuff. >>> >>> >>> >>> >>> >>> >>> >>> On Sun, Jun 27, 2010 at 11:37 AM, Henry Minsky >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> I've got the mostly debugger working with the new text sprite, >>> except for something is still a little broken with vertical scrolling. >>> The simple test case works (test/lfc/maxscroll) , but the debugger >>> text pane itself is not scrolling quite right. It may be that >>> since the debug pane uses some very old scrolling code, it may be >>> depending on some other behavior. >>> >>> But there's a big issue which is the efficiency of setText to append >>> text onto the field. When I click on canvas object to inspect >>> it in the debugger, it takes four or five seconds to display the >>> result, which is almost certainly due to calling setText repeatedly, >>> which causes the whole text flow to be recreated. We need to find >>> out how to efficiently append text into the textFlow rather >>> than reimporting the whole thing from HTML for each call to setText. >>> >>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] <mailto:[email protected]> >>> >>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] <mailto:[email protected]> >>> >>> >>> >> -- >> Regards, >> Max Carlson >> OpenLaszlo.org >> > > > > -- > Henry Minsky > Software Architect > [email protected] > > > -- Henry Minsky Software Architect [email protected]
