Flex 4 Release Build breaks text editor

[bustback01]

I was working on an editor using FB4 beta 2. Fonts were loaded at runtime ... CFF is being used.

In Flex 4 SDK that comes with FB4 beta 2, my spark rich text field sitting in a group in my application looks fine - proper font families applied and renders correctly. My font + style drop down lists are all fine as well.

As soon as I switch to the release SDK, or any SDK later than FB4 beta 2 (well, major releases) the font styles are not longer properly applied to the field. Changes to the family no longer apply to the rich text field.

The rich editable text that I'm using is basically as follows:

                <s:RichEditableText id="editor" fontLookup="embeddedCFF" renderingMode="cff"
                                    focusEnabled="false" x="100" y="50" focusIn="focusInEditor(event)" focusOut="focusOutEditor(event)"
                                    width="300" height="200">
                    <s:textFlow>
                        <s:TextFlow fontFamily="HelveticaNeueLTStd-MdCn">
                            <s:p fontFamily="HelveticaNeueLTStd-MdCn" fontSize="14" color="0x999999">Test first line of text</s:p>
                            <s:p fontFamily="HelveticaNeueLTStd-Blk" fontSize="18" color="0xFFFFFF">Test second line of text</s:p>
                        </s:TextFlow>
                    </s:textFlow>
                </s:RichEditableText>

That probably isn't too important but I figured I would paste it anyway. I'm using setFormatOfRange primarily and this block of textFlow was only to get some initial content into the text area.

There is a ton of other related code for editing, selection, etc. It seems any font family related change does not get applied.

I know there have been a ton of changes and this may be difficult to pin down. However, this is pretty awkward. The application I was building loaded up fine, fonts loaded up all fine and all editing worked perfectly until going to release SDK.

Is there any change that would cause this to happen?

[bustback01]

THIS is the issue:

http://marcel-panse.blogspot.com/2010/03/embedded-fonts-in-tlf-and-swfcontexts.html

So, what can be done about this? I'm building an editor that loads multiple font SWF files that may be from any location, any domain... anywhere.

The single editable text field that will be used will contain multiple fonts from these multiple domains.

I tried to implement the solution shown here but the font families in my editor are still not shown properly.

[bustback01]

Some more specifics...

I am registering the embedded fonts with Font.registerFont(). Flex does load up the font and enumeration works. Fonts display properly in a drop down list with a custom item renderer that shows what the font looks like...but will not apply to a rich editable text component.

I tried avoiding registerFont, setting the ISWFContext an the context of the flow composer, or setting the font lookup in global settings to null. None of those solutions work at all.

Matter of fact, the simple solution shown by Peter in the jira case (with two ttf embedded fonts and a simple flow) will not work ... with my versions of embedded fonts.

That's weird because there is nothing special about the actionscript only project i created to generate the embedded swf files. They are doing everything properly and the right properties are set on the embed. The font is registered and it does display in the UI - only in a drop down list with separate item renderers though.

Any other reasons embedded fonts might break in any build after FB4 beta 2?

[bustback01]

Ok, so I finally got it working but this is not ideal at all. Adobe really needs to give us some direction on how to properly deal with font embedding and TLF now that the release build breaks all functionality with loading runtime fonts and TLF.

Problem:

I am embedding collections of fonts (faces) into single family classes. Each individual face is registered with Font.registerFont(). I need to do this because I have to have mixed fonts within text flows - at least according to Alex H's recent blog post.

Fonts do not display in TLF without doing the following:

1. GlobalSettings.resolveFontLookupFunction = null;

2. editor.textFlow.flowComposer.swfContext = ISWFContext(this.getFontContext("AnyFamilyNameFromAnyFontEmbedded", false, false, FontLookup.EMBEDDED_CFF));

3. Instead of #2, use editor.textFlow.invalidateAllFormats();

Either #2 or #3 need to be performed. If I have a spark richEditableText control in MXML with defined familes from the loaded fonts. I even tried placing the control into a separate state so it wasn't created until after the fonts were loaded... I still needed to invalidate the formats or set the context.

The "AnyFamilyNameFromAnyFontEmbedded" does not need to be all of the embedded family names. It only needs to be one of them. Once one is used, all embedded fonts work. Also, I have to use the internal namespace to even get access to getFontContext, another oddity that, in my humble opinion, should never be necessary to create mixed style TLF content.

My questions are then:

1. Why am I required to use ISWFContext if I am using Font.registerFont()?

2. Why is GlobalSettings.resolveFontLookupFunction = null; also required for this to work?

3. What is the recommended workflow to embed fonts from multiple SWF files into the release build and have it work without having to jump through all these hoops?

[rdermer]

I believe Flex has a different system for registering fonts.  The idea of the SWFContext is to route the createTextLine and related calls to the SWF that knows about the font.  Flex has taken control of this and is unfortunately impacting your non-Flex TextFlow.  Clearing GlobalSettings.fontLookup is going to break Flex.  I think the answer for you is to use the Flex font embedding APIs.

Hope that helps,

Richard

[bustback01]

Unless I misunderstand the whole Font.registerFont() method, I was under the assumption that once that is called, that font is available.

This is a Player feature, not a Flex framework feature. It is a feature that Flex and TLF combined break (works fine in Flex with components and skins).

I'm happy to do it however it's suggested. I'm using Spark richTextEditor component and using declared textFlows in MXML. The textFlow itself has declared fontFamily and the font is loaded prior to the instantion of the flow on the richTextEditor control. This is all flex... I am not creating textFlows or doing runs or dealing with container controllers through AS ... yet.  I was heading that direction with this editor but ... well, runtime fonts aren't working ...

If you create a text flow in Flex with mixed fontFamiy information (p, span, etc) and these familes come from runtime loaded fonts: applying a single SWFContext for one of the loaded fonts causes all other loaded fonts to immediately work ... but only if you've overridden the global settings for fontLookup to return embedded or null.

Should I be asking this to the Flex folks and not on the TLF forum? This is TLF ... just TLF within Flex.

[casper_no]

I have been tearing my hair out over the same issues. Mine first popped up when going from beta to release as that meant that RSL (runtime shared libraries) was default. And that meant that TLF classes were loaded in a different context than my embedded fonts. Arg!

The #2 solution worked for me, as did changing Properties/Flex Build Path/ from RSL to "merge into code"

Hope a future release makes font embedding and TLF a bit easier to handle - debugging this has been really hard.

[bustback01]

Agreed. Unfortunately, we have no solid answer from Adobe on how this should be done.

Alex's post clears up the confusion and need for the ISWFContext. However, that does not work right. Only one context is necessary to allow all fonts to be applied to spark controls (RichEditableText). According to Adobe, the spark controls are supposed to handle that internally and work properly (they do not).

It would be nice to get a solid direction at some point in time. For now, we are stuck setting the global settings font lookup method to null or to always return "embedded" and need to call the invalidateFormats() on richEditableText instances, or set a single SWFContext instance. Absolutely not an ideal workflow.

This change from beta 2 to the release with regards to the font embedding is a major point of contention and an issue that breaks existing code. I think it's an issue with the Flex 4 framework and not necessarily TLF. However, because they are intimately related, either team should be able to provide some solid direction. I just hope we get something, sometime.

I haven't come up with a solution yet that is stable and makes sense. If I do, I'll be sure to post it here.

[rdermer]

Somehow you want to condititionally use the Flex function and otherwise do your own thing.

Basically this function really needs to be configurable per TextFlow and should move to Configuration instead of GlobalSettings.

How about this:

// for the editor's swfContext set a known value

textFlow.flowComposer = editorSwfContext

Then write your own GlobalSettings.resolveFontLookup that looks like this:

import spark.utils.TextUtil;

public static function editorFontLookup(
                    swfContext:ISWFContext, format:ITextLayoutFormat):String

{

    if (swfContext != editorSwfContext)

     return TextUtil.resolveFontLookup(swfContext,format);     // let flex do its thing

   // return the calculation appropriate for your editr

}

Hope that helps,

Richard

[casper_no]

This would probably work just fine, but the real problem is that the TLF + Flex combination forces to jump through these hoops in the first place. I know I spent a lot of hours trying to debug why my embedded fonts wouldn't show, with no helpful errors or warnings from the framework.

Issuses like these are not showstoppers, but they make TLF hardere to use, which is a shame. I love the power and typographical precision of TLF, a pity it such a hassle.

[rdermer]

There is an open flex bug on this issue.   A more robust workaround is posted in the comments:

http://bugs.adobe.com/jira/browse/SDK-26187

Hope this helps,

Richard