Originally I intended this post to be a series of examples demonstrating some of the hassles involved when dealing with multi-lingual content in Flash. But it occurred to me that the issue isn’t so much that Flash is difficult for this purpose, it’s more that it’s lousy. It’s way behind the curve considering where the rest of the web is today in this regard, and incredibly the situation was far worse not much more than twelve months ago (before Adobe released Flash CS5 and the Text Layout Framework).
The rationale for this post came after attending a talk at SXSW 2011 — ‘Flash is Dead, Long Live Flash!‘. The presenters, Elliot Chong and Toby Miller, gave a great overview of strengths and weaknesses of both Flash and HTML 5. However, one point of debate they missed was localisation. Not that I expected to hear it, but I feel strongly about such things considering this is a big part of my day job. During the Q&A session, I brought up the point of localisation — but explaining technical trivialities on the spur of the moment in front of a large crowd of peers can be tricky: hence this post.
Let’s start with the simple things. Now Flash actually provides fine support for most languages — even Chinese and Japanese are OK. Until you get into complex scripts — we’re talking Arabic, Fari, Hindi, Urdu and many more. Basically any alphabet that changes the ligatures between characters, depending on the characters present.
Caveat: I’m a designer first and developer second… if I’ve got something wrong here please let me know — anything new I can learn to make my life easier is always appreciated!
So, let’s look at what problems Flash will give us trying to put Arabic text on to the stage. Let’s use the Arabic word for kitten. This is how it appears correctly rendered in plain old HTML (right aligned since Arabic is read right-to-left — another point to touch on, but we’ll get to that later).
Now, let’s try and show the same text in Flash…
Example one: classic text field (SWF size: 4kb)
The simplest way to put text on the stage in Flash is with a simple text box. Just create it on the stage, copy your text, and you’re away. But no, not with complex scripts. For some reason Flash is incapable of rendering the ligatures between characters together correctly in classic text fields. And the web is full of depressing forum posts about people enduring frustrations at what appears to be such a trivial thing.
Example two: dynamic text field (SWF size: 4kb)
Again, this renders exactly the same as example one. Having dashed your hopes of static text displaying properly, surely you didn’t expect to be able to use dynamic text fields?
Example three: Text Layout Framework (TLF) text field (SWF size: 52KB)
Hoorah! OK, so some credit to Adobe here — so you can display complex scripts properly straight on the stage. But only if you use the new Text Layout Framework, which requires Flash CS5 and Flash Player 10+. And you can expect an additional 50kb on top of the SWF size! Prior to Flash CS5′s release in April 2010, this was all but impossible: the only way to display complex scripts in Flash properly was either as a vector exported from something like Illustrator (which, by the way, has supported complex scripts for a long long time) or as a bitmap from Photoshop (again, supports complex scripts).
Example four: programmatic text field (SWF size: 52KB)
Let’s try creating the text field with ActionScript:
var myFormat:TextFormat = new TextFormat();
myFormat.color = 0x233515;
myFormat.size = 76;
myFormat.font = "Arial";
myFormat.align = TextFormatAlign.RIGHT;
var myTextField:TextField = new TextField();
myTextField.text = "القطط";
myTextField.width = 190;
myTextField.height = 100;
myTextField.selectable = true;
myTextField.y = 6;
myTextField.defaultTextFormat = myFormat;
Well, at least Flash renders the text in the correct order, but it still doesn’t correctly render the ligatures.
Example five: programmatic Text Layout Framework text field (SWF size: 112KB)
Let’s try creating the text field with ActionScript using the Text Layout Framework:
var markup:String =
"<TextFlow xmlns='http://ns.adobe.com/textLayout/2008' fontSize='85' color='#233515' textIndent='15' paragraphSpaceAfter='15' font='Arial' paddingTop='25' paddingRight='25'>
var textFlow:TextFlow = TextConverter.importToFlow(markup,
textFlow.flowComposer.addController(new ContainerController(this, 200, 100));
textFlow.interactionManager = new SelectionManager();
Hoorah, Text Layout Framework comes through again. But look at the file size now: 112KB. That’s 28 times the size of creating a simple text field programmatically.
Of course Text Layout Framework gives you a huge amount of text control, so the larger file size is somewhat understandable — but that big? Just to render a simple word?
These are all very simple examples, but just imagine how much more complex most projects will get in Flash if localisation is required. The extra complexity (and increased file size) from using Text Layout Framework would surely discourage most developers from using it, particularly if there is no need for localisation at the beginning of the project. This introduces a potential nightmare scenario of rewriting entire applications to use Text Layout Framework.
Other gotchas with Flash and localisation
Embedding fonts in your project? Your standard Latin character set (which covers most European languages) is pretty light weight. Let’s look at kitten in other languages:
Example six: Latin font embedding (SWF size: 55KB)
Even adding in Latin I, Latin A and Latin B extended character sets for a font only adds about 56kb to your file (using Arial Unicode as your font). That’ll cover pretty much any Latin-based alphabet, from Icelandic through to Turkish. But now, let’s add Cyrillic and Greek.
Example seven: Latin, Cyrillic and Greek font embedding (SWF size: 85KB)
Now we’re looking at another 32kb on top — 85kb in total. Now that’s really not much… but let’s now look at Chinese and Japanese.
Example eight: Latin, Cyrillic, Greek, Simplified Chinese and Japanese font embedding (SWF size: 3.8mb)
For an embedded font that covers Latin, Cyrillic, Simplified Chinese and Japanese — you’re looking at a whopping 3.8mb.
So, if you’re planning on localising with dynamic Flash applications across many languages, you have two choices:
- Don’t embed fonts, just use device fonts — you’ll lose your nice text on many PCs, but your file size will be manageable
- Embed fonts but create different files for each language — again, file size manageable but then you’re re-creating a whole bunch of files, and maintenance can become quite a nightmare if you’re not careful
The right-to-left UI
Many right-to-left (RTL) languages are also complex scripts, so we’ve got a bit of a double-whammy here. Arabic, Farsi, Urdu… and even Hebrew (although at least that’s not a complex script!). Since RTL users read right to left, a good UI designer will re-align the interface in the same way: for instance, check out Google Israel or Google in Farsi, and notice how the entire screen is ‘flipped’ around. Even close buttons on dialogue boxes get flipped (such as this example from GNOME on Linux).
This means you should do the same for all UI inside your Flash application. While it’s a bit of a hassle at first, what I’ve found causes the most problems when doing this is Flash’s Cartesian coordinate system — X and Y works great for left-to-right, but not so for right-to-left.
Align an object to the top left? Easy:
But for RTL, we want it on the top right.
When you’re doing that for all your UI elements, it can turn into a real chore. Never mind if you run into stage.Width calculation bugs which do happen when viewing the SWF in various browsers.
Much, much easier! (Of course, there are plenty of browser bugs with CSS too, so it’s by no way perfect, but it is much better).
Flash UI Components
Using Flash’s inbuilt UI Components will cause you some problems too. You can move the scrollbar on a scrolling TLF text field to the right at least (you can do this programmatically, too):
Example nine: right-to-left scrollbar (SWF size: 119kb)
But it appears many other components (such as the combobox) have no TLF support or the ability to make them more RTL friendly (all the text below is rendered incorrectly in Arabic):
Example ten: other Flash UI components (SWF size: 49kb)
For anyone looking at creating Rich Internet Applications that will work across different locales, given the growing market acceptance of CSS3, HTML5 and already accepted tools such as jQuery, Flash is looking like a really hard task for such work.
But disregarding all those points, let’s go back to the main thrust of this post: why is Flash so lousy at localisation? There are an estimated 65 million Arabic users online, and if you want to use Flash to provide content for these users, you’re in for a ludicrous development experience. For me, it’s really not good enough. Years ago Flash was targeted as being highly inaccessible, and even though it has made good progress, it’s highly inaccessible in another way: that of localisation.
Download example Flash files from this post (1mb).