Here's a note from adobe regarding using the TLF (txt layout framework) in apps
http://help.adobe.com/en_US/flash/cs/using/WSb03e830bd6f770ee-4b0db644124bbdb363d-8000.html#WSb03e830bd6f770ee72b69dc71257a25aa72-8000 It sez: Publishing SWF files with TLF text To function properly, all TLF text objects rely on a specific TLF ActionScript library, also called a Runtime Shared Library or RSL. During authoring, Flash provides the library. At runtime, after you have uploaded your published SWF file to a web server, the library is provided in the following ways: 1. The local computer. Flash Player looks for a copy of the library on the local machine it is playing on. If the SWF file is not the first to use TLF text on that computer, the computer already has a local copy of the library in its Flash Player cache. Once TLF text has been in use on the Internet for some time, most end-user computers will have a local copy of the library file. 2. On Adobe.com. If no local copy is available, Flash Player will query Adobe’s servers for a copy of the library. The library only has to download one time per computer. After that, all subsequent SWF files that play on the same computer will use the previously downloaded copy of the library. 3. Next to the SWF file on the web server. If Adobe’s servers are not available for some reason, Flash Player looks for the library in the web server directory where the SWF file resides. To provide this extra level of back-up, manually upload the library file to the web server along with your SWF file. More information about the assets file is provided below. When you publish a SWF file that uses TLF text, Flash creates an additional file named textLayout_X.X.X.XXX.swz (where the X’s are replaced by the version number) next to your SWF file. You can optionally choose to upload this file to your web server along with your SWF file. This allows for the rare case where Adobe’s servers are not available for some reason. You can also avoid the need for Flash Player to do a separate download of the TLF assets by compiling the assets within your SWF file. You can do this in the ActionScript settings of your FLA file. However, remember that these assets add significantly to the size of your published SWF file and is not necessary in most cases. To compile the TLF ActionScript assets in published SWF files: 1. Choose File > Publish Settings. 2. Click the Flash Tab. 3. Click the Settings button next to the Script menu. 4. Click the Library Path tab. 5. Select Merged Into Code from the Default Linkage menu. The following are recommendations for handling the TLF library for different deployment scenarios - Web-based SWF file: use the default behavior of allowing Flash Player to download the RSL if necessary. - AIR-based SWF file: Compile the RSL into the SWF file. This way text functionality of the AIR application will not be compromised while offline. - iPhone-based SWF: It is not recommended that you use TLF on the iPhone for performance reasons. If you do, compile the TLF code into the SWF because the iPhone cannot load RSLs. Note: For more information about how the Flash Player cache works, see Improving Flex application performance using the Flash Player cache<http://www.adobe.com/go/learn_fl_flash_player_cache_en>.The article focuses on Flash Builder, but all of the information about the Flash Player cache applies to Flash Professional as well. When the TLF ActionScript assets are not embedded or available on the local playback computer, there can be a slight delay in SWF playback while Flash Player downloads the assets. You can choose the type of preloader SWF that Flash Player displays while the assets are downloaded. You choose the preloader by setting the Preloader Method in the ActionScript 3.0 settings. To set the Preloader Method: 1. Choose File > Publish Settings. 2. In the Flash tab, click the ActionScript 3.0 Settings button. 3. In the Advanced ActionScript 3.0 Settings dialog box, select a method from the Preloader Method menu. The available methods are: - Preloader SWF: this is the default. Flash embeds a small preloader SWF file inside your published SWF file. This preloader displays a progress bar while the assets load. - Custom Preloader Loop: use this setting is you want to use a preloader SWF of your own. The Preloader Method setting is only available if the Default Linkage is set to Runtime Shared Library (RSL). <http://help.adobe.com/en_US/flash/cs/using/WSb03e830bd6f770ee-4b0db644124bbdb363d-8000.html#top> On Thu, Jun 3, 2010 at 3:46 PM, P T Withington <[email protected]> wrote: > There's always the possibility that it is an Adobe bug! > > On 2010-06-03, at 15:35, Henry Minsky wrote: > > > Also, we almost certainly do want to be having our new apps load the flex > > runtime shared libraries, because the > > text layout engine and framework libraries are pretty large, and it seems > > dumb to have them linked statically, unless there's some reason to > believe > > that those libs will not be present in Flash 10 client installs by > default. > > How do we find out whether that's the case? > > > > > > So we need to figure out how to make the preloader work properly with the > > updated flex compiler. > > > > > > On Thu, Jun 3, 2010 at 3:28 PM, Henry Minsky <[email protected]> > wrote: > > > >> OK, so the flex compiler was helpfully trying to tell me what was wrong, > >> but i was not looking at it's error output, since the SWF9External > driver > >> seems to just discard it. > >> > >> The flex compiler said > >> > >> [java] Stray error string from external compiler: > >> > /private/var/folders/xh/xhmdrA41HCKjjiditeqN1k+++TI/-Tmp-/lzswf9/build/explore-nav/LzPreloader.as: > >> Warning: This compilation unit did not have a factoryClass specified in > >> Frame metadata to load the configured runtime shared libraries. To > compile > >> without runtime shared libraries either set the > >> -static-link-runtime-shared-libraries option to true or remove the > >> -runtime-shared-libraries option. > >> > >> > >> And so I added in "-static-link-runtime-shared-libraries" to the > compiler > >> command line, and it > >> worked. > >> > >> So they question remains, why does the Preloader cause the runtime to > >> instantiate something from the > >> "mx.core" package, and why did it not used to do that in earlier version > of > >> the flex compiler and > >> framework .swc libs. > >> > >> > >> > >> > >> > >> > >> On Thu, Jun 3, 2010 at 1:23 PM, Henry Minsky <[email protected] > >wrote: > >> > >>> I downloaded a much more recent flex compiler milestone build (March > 2010, > >>> flex_sdk_4.0.0.14159) > >>> in order to get the updated Text Layout Framework class libraries, as > well > >>> as numerous compiler > >>> fixes. > >>> > >>> However, when I compile an app now, and try to run it, I get this error > >>> during startup > >>> > >>> VerifyError: Error #1014: Class mx.core::MovieClipLoaderAsset could not > be > >>> found. > >>> > >>> at flash.display::MovieClip/nextFrame() > >>> at > >>> > LzPreloader/enterFrame()[/Users/hqm/openlaszlo/lib/jakarta-tomcat-5.0.30/temp/lzswf9/Users/hqm/openlaszlo/trunk2/test/tlf/build/edit/LzPreloader.as:20] > >>> > >>> > >>> Something in the preloaded is trying to reference a class that we don't > >>> have compiled into the app? > >>> > >>> Does this ring a bell with anyone? > >>> > >>> note, the preloader code lives in > >>> WEB-INF/lps/lfc/kernel/swf9/LzPreloader.as, but a copy of it that > actually > >>> gets inserted into the > >>> app is hardcoded into SWF9Writer#makeApplicationPreamble > >>> > >>> > >>> > >>> > >>> -- > >>> Henry Minsky > >>> Software Architect > >>> [email protected] > >>> > >>> > >>> > >> > >> > >> -- > >> Henry Minsky > >> Software Architect > >> [email protected] > >> > >> > >> > > > > > > -- > > Henry Minsky > > Software Architect > > [email protected] > > -- Henry Minsky Software Architect [email protected]
