Thanks, Alex. In the meantime I did find a way to reproduce that mandelbug<http://en.wikipedia.org/wiki/Unusual_software_bug>, and I've described it here<https://issues.apache.org/jira/browse/FLEX-33779> on the Apache Flex Jira. It's a hell of a bug in terms of necessary prerequisites. If I could see the source of TextBlock or if I were a font expert I could probably go further with the investigation, but that's where I had to leave it.
I hope some of you have ideas around it. If it is, indeed, related to code in TextBlock, then it might even be a Flash Player issue. Or it could simply be a badly formed ttf file (though I did download the same ttf from multiple sources, but you never know). Whatever it is, I am very curious. On 24 September 2013 17:44, Alex Harui <[email protected]> wrote: > > > On 9/24/13 8:39 AM, "Mihai Chira" <[email protected]> wrote: > > >Hi, > > > > > >I found a (really complicated) way to reproduce a bug in Label.as (the one > >that caused FLEX-33747 > ><https://issues.apache.org/jira/browse/FLEX-33747>), > >and as I'm trying to discover its cause I find myself stuck seeing > >different behaviours of TextBlock.recreateTextLine(). When it's buggy it > >returns a TextLine (and then 9 more after that, in the same loop), while > >in > >the bug-free scenario it returns null. > > > >(How) Can I access the source code of that function? How about the rest of > >TLF? It will help me produce a bug report, as I need to find a way to > >isolate those conditions. It would be great to have it in for the 4.11 > >release. > TLF is in Apache Flex Git in the flex-tlf repo. > > TextBlock and other flash.text.engine classes are part of the Adobe > runtimes. They are written in C++ and the source is not available. > > In my limited experience with TLF, TextBlock.recreateTextLine gets > involved when the compose width and/or TextElement changes. So it is > usually other code that is causing TextBlock to do different things. > > -Alex > >
