Archive for November, 2008


Future of Flash typography

I just saw the presentation of the newly released Text Layout Framework beta on Adobe Labs. It seems to have drowned in all the other announcements from MAX. For us this is great news – our main product (Print) requires typographical precision and we’ve been forced to make complex code and workarounds to achieve the desired degree of control with the current player API.

– text flow between text fields (or the new equivalent). Allow text flow around arbitrary shapes.
– ligatures. Yes! Finally! One less thing to be envious of InDesign for.
– in-line images. Logos, graphics within the text flow? Sci-fi only last year.
– right to left languages. We’ve had projects stopped because FP currently doesn’t support Arabic or Hebrew.

I was waiting for Adobe to update Flex to handle the new FP 10 API and start writing high level text and typography components, but it looks like much of the work has been done for us. Can’t wait for the release version.  Then the integration work begins – we need to implement code to output PDFs that look exactly like what you have on screen.


Tweening trouble

We had an odd problem in our new framework. We’ve centralized tween instantiation to a TweenManager class, a practical way to instantiate tweens without having to type the whole code shebang every time. It looked good, but after a while we noticed that sometimes the tween never finished properly. More research showed that it didn’t fire its TWEEN_END event. And it happened without any clear pattern. Some projects’ tweens worked ok, others not. Some worked one day, not the next. A debugging nightmare.

A bit of searching online showed that we weren’t the only ones experiencing this. The reason was that we assigned the tweens to variables within a function. As there was no other reference to it, it was eligible for garbage collection. And the flash player’s garbage collection happens when it wants. So sometimes the tween would be garbage collected before it reached the end and no event was fired.

It was fairly easy to fix – we now store references to the tween in a Dictionary and delete them on TWEEN_END

old code:

    var t:Tween = new Tween(targ, prop, options.ease, targ[prop] ,value, secs, true);
        //add listener for end of tween
        t.addEventListener(TweenEvent.MOTION_FINISH, function():void {
            t.dispatchEvent(new Event(TWEEN_END));

revised code – we store options in a dictionary to be able to do different operations on end (like hide after fade out)

    if (_myTweens == null) _myTweens = new Dictionary();
    var t:Tween = new Tween(targ, prop, options.ease, targ[prop], value, secs, true);
    _myTweens[t] = options;
    //add listener for end of tween
    t.addEventListener(TweenEvent.MOTION_FINISH, onMotionFinish);

and clean up references with.

    private function onMotionFinish(e:Event):void {
       var t:Tween = Tween(;
       var options:Object = _myTweens[]
       if (options.hideAfter) t.obj.visible = false;
       delete _myTweens[t]

The big AsDoc race

Well, not so much of a planned race as a coincidence. I work on a winXP pc at work and on an iMac at home. Thanks to Adobe’s fair policies, I can use the same licence on different systems at home and at work. Good work guys.

Right now, I’ve done some revisions to the AsDoc comments in the framework, tried out some of the tags for documenting events, packages, etc. This means running the ant script that runs AsDoc quite a few times. Ant outputs time elapsed as default. My work pc, a 3Ghz Pentium D takes about 44 seconds. My iMac at home – 2.8Ghz, not latest model – takes about 24 seconds. I have no idea if this is due to Java implementation differences or maybe AsDoc just runs faster on a mac, but still. On the whole, Flex Builder feels faster at home, but I don’t have any hard numbers to show.

Addendum: Just got a new Quad core PC, still running XP. It did it in 28 seconds. We’ve added quite a bit of code since the first comparison so it’s not a fair race.


Continuous Integration and Flex

Our server-side programmers have a continuous integration system up and running. Using CruiseControl.Net, most of our sites are tested every time framework updates are committed to subversion. It is useful (bugs are detected early) and it gives you the good feeling of work being done without any effort on your side.

I have been envious of them for a while and wanted a similar set-up for Flex projects. I found a good, thorough description here and assumed that this would be fairly easy. I’ve been wrong before. It took lots of time, partly because the instructions are for a Java environment and we’re running .net versions.

First problem was that the ant dialect supported directly by CruiseControl.Net – Nant – isn’t really compatible with Apache.ant. Frustrating. So then I installed Java JDK and Ant. This worked a whole lot better, ant scripts used in Flex ran without problems. But that meant calling .bat files that called the ant xml that did the compilation. I’m not very good with either bat or ant syntax, so this was awkward.

With the assistance of Papirfly’s alpha-nerd, it got sewn together. The hardest problem was that errors weren’t detected until we rewrote the ant.bat, i.e. the script that runs the ant scripts. We added

if not errorlevel 0 exit /b %errorlevel%

in bin/ant.bat, line 134 – that is in the :runAnt part of the script. The side effect is that if you run ant manually in the console, it will just close if ant encounters an error. Best to use it only on the machine running CruiseControl.

The end result is a satisfying system where Flex projects are also complied (or rather attempted) on committed framework changes. We also build fresh documentation of our framework with asdoc – look ma, no hands!

Spending a day and a half to avoid boring menial tasks – that what being a nerd is all about!