As per my previous post here, I’ve made some improvements to my method for proper Arabic rendering in a dynamic TextField using ActionScript 2.0.
An ActionSctipt 3.0 version available here
Many thanks to all reviewers, your comments were very helpful bringing this version available, now you can use and test my new parseArabic method ..
Requirements:
- Dynamic TextField
- HTML Enabled TextField
- Pre-Defined TextFormat
- Arabic Fonts must include a complete Arabic Presentation Forms-B (glyphs from FE70 to FEFE according to the Unicode Standard 5.2)
Features Supported:
- Embedding Fonts (just put a dynamic textfield on-stage and select at least Basic Latin (95 glyphs) and Arabic (1088 glyphs) from the Character Embedding menu).
- Arabic Ligatures.
- Word Wrapping.
- Bi-Directional text.
- HTML Text.
- Loading External text.
Features Not Supported:
- Arabic Diacritics.
Fixed Bugs:
- Correct Arabic Ligatures with/without embedding fonts
- Correct Brackets Directions
- Clean Line-Breaks
Here is an example works with this external XML file:
download the above example here
Note:
When you try to select and copy the above text into a static TextField it will display Arabic properly as well, just another benefit of this method, but if you paste the copied text into any other text editor you will see an alien version instead!
Update: a newer version available here
Well, this issue is a very old one, I’ve always experienced annoying problems each time I try to render Arabic text on run-time using Flash and ActionScript 2.0, Flash doesn’t support right-to-left languages, and when it comes to Arabic, we are talking about proper characters joining and word wrapping ..
I never stopped tracking this specific issue, googling it to find any new solution has been developed somewhere, for a long time I can only find this one, the guy have it perfectly solved, he was having his solution implemented using ActionScript 2.0 at some point earlier, but he stopped publishing that and kept his latest version only, which works with ActionScript 3.0, and for old fashion guys like me he left another version to manually copy proper Arabic text using an AIR application he developed here
Recently, Adobe says that they finally supports right-to-left languages along with bi-directional and complex script ones, only using ActionScript 3.0 and it requires Flash Player 10 or above, they even have an open source framework called Text Layout Framework, it’s perfect actually, it should put an end to this issue, but ..
I have my own objections, I made my quick test to check their new technique here, Arabic text is finally rendered properly, but why we have to add so many childs to our display list from different TextLines and TextBlocks instead of a single TextField? also we have to set a max width, and I couldn’t find a way to scroll through text unless I used a custom scroller and masking the text just like any other MovieClip or DisplayObject, personally, I find this much complicated experience just to display simple string!
I do like ActionScript 2.0 a lot more anyway, not just for handling text easily, but for many other reasons, I can stop to post another article to explain why I’m saying this, right now we need to know what I’ve reached regarding to our issue ..
In a nutshell, ActionScript 2.0 used to refuse right-to-left languages, so we can’t embed fonts, wrap text properly, and when it comes to Arabic text we also see our characters splitted which is inappropriate for Arabic readers, the old solution for this was loading text encoded in UTF-8 from external text/xml files, and still no word wrapping, and on Mac machines Arabic letters still splitted, we can align text but its direction still not right-to-left ..
So, logically, I know that I have to construct my Arabic text manually, to achieve that I had to analyze Arabic rules for character joining with all it’s special cases, and then find a way to force its direction to be left-to-right, and the word wrapping part is not that hard after all, this is basically what I did actually!
My only problem was in finding a way to inject all proper Arabic characters with its unique cases, for a long time I found that very difficult, Flash doesn’t allow me to copy those from other text processing tools, and of course there’s no way to type each character a lone in different cases using keyboard ..
Finally, I found a way to do that, and it was extremely simple! I found these charts at unicode official website, and that’s it! now I can instruct ActionScript 2.0 to handle my Arabic characters properly!
You’re most welcome to use and test my parseArabic method, it supports word wrapping, right-to-left, bi-directional (inline English characters), embedded fonts and custom text formats, here is an example:
download the above example here
The above approach doesn’t support html tags yet, it’s a bit confusing, but as I said, you’re welcome to contribute, your reviews can help improving the code ..
This may help any ActionScript 2.0 loyal friend, and I think the same approach can be used for ActionScript 3.0 as well, I will post that soon ..
I had my older AIR 1.1 application which uses encrypted local store data for saving specific settings per user, today when the AIR runtime gets updated to version 1.5 my application turned to a total mess!
I’m using various classes in my simple application that might cause this issue as far as I thought, like loading CSS on runtime or loading conditional states and components depending on certain parameters retrieved at login ..
I spent a few hours hunting down what actually happened and at last I think I figured it out ..
The new AIR has 3 new features, encrypted local databases, Flash Player 10 capabilities and the new WebKit update, it seems that Adobe somehow has made a change regarding to how the AIR runtime read and write the encrypted local data, and a simple try and catch block of code just revealed the problem ..
The following example assumes that there is encrypted data stored using an older version of the application complied using AIR 1.1, and the application checks for a certain key for loading the perspective CSS file, since the new runtime may not able to read the older version of the encrypted data then it should throw an error, at this point I reset any previous saved data and load a default CSS file in order to bypass this issue when any client update to AIR 1.5
var skinBytes:ByteArray; var styleEvent:IEventDispatcher; try { skinBytes = EncryptedLocalStore.getItem("skin"); if (skinBytes != null) { styleEvent= StyleManager.loadStyleDeclarations("css/"+skinBytes.readUTFBytes(skinBytes.length)+".swf"); } else { styleEvent = StyleManager.loadStyleDeclarations("css/black.swf"); } } catch(e:Error) { //Alert.show(e.message); EncryptedLocalStore.reset(); styleEvent = StyleManager.loadStyleDeclarations("css/black.swf"); }
Well, this is not an intelligent solution at all, cause these saved data my be much more complicated and I should not force my user to have it all wiped out just for upgrading the runtime!
Anyway, I’m not sure if my conclusion about the encryption handling change between AIR 1.1 and 1.5, especially that Adobe didn’t mention anything regarding to this particular issue as fas as I know, but I thought that may be this help someone else experiencing the same problem when migrating his application to the new AIR runtime ..
I was working on a weekly events module ..
At some point I need to be able to get a list of week days by providing only on day, for example if I provide today date I expect the whole week contains today regardless to the current month or years ..
The following example shows how we can do that, with some extra features ..
source code available via flash context menu


(6 votes, average: 4.33 out of 5)