I have the same problem in our project, we are allowing users to zoom a container that contains images and text (RichText, RichTextArea).
When I set scaleX, scaleY to the container, which is higher or lower than 1, the text is unreadable, sometimes the space between the characters is the same as between the words.
TLF is very good framework and I see a lot of work behind it, but this bug makes the text layout framework useless. Its really a nightmare for flash projects with tlf.
Has someone the solution for it?
I forgot to tell the platform I am using.
I am on desktop Windows (both XP and VISTA).
I have also tried to compile the same application as Flex Mobile Project, and it works fine, text scaling is perfect on both mobile device and standalone mobile flash player.
It looks like the problem is in some swc library for the Flex Project, which has better version in Flex Mobile Project.
How about an embedded font with cff true?
@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/halo";
This solution is not suitable for our project, because its multilingual, we use a lot of dynamic text saved in xml files, so embedding all fonts in all languages is almost impossible.
But as I said, device fonts are rendered perfectly when scaled if I use RichText or RichEditableText in Flex Mobile Project in Flash Builder (flex SDK 4.5.1).
I have also tried it on my mobile device (PlayBook), and font is nice and sharp when zooming (gestureZoom) in the application.
This problem occurs only when using Flex Project (air or web).
But anyway, thank you for your fast response!
Embedding is the only way to guarantee visuals. You can create RSLs or modules containing a font or fonts and they will end up in the browser cache. You’ll see a delay when the font SWF is not in the cache, but then each newsletter doesn’t need to have the fonts in it.
Sorry, but I can not accept this as answer. If you told me that six years ago, I could think about it for a while, but today in 2011 (2012), when we have TLF 3 and the Flash Player 12 is behind the door?
What is the main purpose for having text component in the application? That people can read the text. In 2005 we had flash 8, we could not apply alpha and rotation on dynamic textfield with device fonts, but "cacheAsBitmap" did the trick, so after that we could scale, rotate and apply alpha. Doesn't matter that text was jumping when scaled, but it was still readable.
Now we have great FTE and TLF framework, we can write from right to left and from the top to bottom, we have striked text, multicolumn text, we can use ordered and unordered lists in html text, we can apply alpha and all transformations on the text and we can do it especially with device fonts (I thought that TLF was build mainly for working with device fonts?). But we cannot scale movieclip with the dymamic text within, because the text is unreadable. Is this the upgrade?
I cannot use spark TextArea, RichText and RichEditableText in my desktop projects, but really I think it must be something with the spark skins, because the text scaling works great in Flex Mobile Project.
Can you please advise me, which text component to use when I need zooming in my desktop / web application?
If Mobile components are working for you, you are welcome to use their skins in your desktop project, but I’ve heard just as many complaints about zooming device text in TextField as well as TextEngine/TLF. The mobile components are using TextField.
I don’t know of any other way if you want the font renderer to render at different scale. Otherwise you are back to bitmaps and their limitations.
I can use mobile skins for RichText and RichEditableText components for desktop and web projects, but there is a little problem. They have no mobile skins and they are paradoxically not recomended by adobe to use within mobile projects, because they are heavy. But they work great even if they are scaled. Do you still think that this is not a bug?
"Try to avoid using the RichText and RichEditableText controls in mobile applications. These controls do not have mobile skins, and they are not optimized for mobile applications. If you do use these controls, you are using TLF, which is computationally expensive."
Is there any chance that this bug will be resolved soon, or do I have to go back to 2004 and make my own class extended from TextField? :-))
I don’t expect device font rendering to handle zoom any better than it does today. Instead of using RichEditableText you can use Spark TextInput with the mobile skin which should swap in a TextField.
I have the same problem. Have you found the solution for this ugly letter spacing problem?
I have done it in stupid but working way - I set fontSize to twice more and scale down... then when you scale it bigger it looks ok (not ideal but much better)