Few of the world's older languages are written from Right-to-Left, as opposed to Latin Left-to-Right. Such languages include Hebrew and Arabic. Writing in the opposite direction than the rest of the world turns to be a bit problematic.
If you belong to the right-handed
majority of the population, you are more likely to smear the ink
while writing right-to-left, since your fist will be hovering over the text you've written already and resting your fist on the paper while writing will have futile results (unless the ink gets absorbed immediately). Some will claim
Right-to-Left scripts are the left-handed conspiracy
Also, at least as it is with Hebrew, you'll need to reserve some space in front of the numbers you're going to write, since the numbers (the Arabic Numberals we all use) go left-to-right. Inserting left-to-right (e.g. English) words and phrases into the text demands you to reserve space too.
Computer application support of bidirectional languages requires much more effort than usual languages with unique alphabets. With regular languages, you'll simply make up a new 8-bit character set
), map your keyboard and all your legacy applications
are set. Bidirectional languages require you to display the text with reversed strings, going through a special BiDi algorithm
, create special input widgets etc. Simply "reversing it all" isn't acceptable, since we have "mixed" sentences, with numbers and occasional English (or any other left-to-right script) names and phrases.
Hebrew support on modern systems is achieved with support on the widget ("control" in Microsoft-speak) level (e.g. in Hebrew-enabled Microsoft Windows and Apple's Hebrew support), modifying the text printing routines and the input widgets. This will provide Hebrew support in simple applications "transparently". Further work is usually required to make a complex application support Hebrew (e.g. a web browser, a word processor).
Bidirectional text can be stored either:
"Visual" is the old way, which required no Hebrew support at all on legacy viewer applications (text viewers, browsers), while Logical is known as the right way (according to Microsoft
and The Unicode Consortium
). The Unicode Standard Annex #9
defines the BiDi algorithm which should be used to convert Logical strings into their visual form (typically to be rendered on the screen, on paper etc.). Complete description of the issues involved in BiDi (run direction, overrides etc.) are out of the scope of this node.
In the 1960s, some Israeli doctor had proposed a system called "The Karmelitic Script", which offered to transliterate Hebrew in English, left-to-right, and put an end to the madness, but it never caught on. In 1985, Apple introduced integrated Hebrew support (on the widget level), and so has Microsoft Israel (at least since Windows 3.0). X toolkits are very slow catching up on this field (there were Hebrew-supporting Motif versions for years, but toolkits such as Qt and Gtk only begun supporting Hebrew around 2001). This is one of the blocks on the entrace of free desktops into Israel and Arabic-speaking countries.
Arabic also has the further complexity of being a rather beautiful script, where different letters are connected to one another (ligatures), and their shapes vary depending on their location in the word (first letter, middle letter, final letter). When typing, after you type-in a letter, the letter before it will change from its "final" form to the interconnected form. That's an issue to be taken care of by the text rendering engine.