To bring the Arabetic scripts and typography back to a user focus, we have been working on an alternative input method to the prevailing one today. The proposed method, NAIM, works in harmony with, and as close as possible to, how users actually write and visualize Arabetic characters in a word while it is being typed. It works best with a two glyphs per letter model but can be implemented in today’s widely used four glyphs per letter model as well. As a background, the two-glyph per letter model consists of one unique ‘normal’ glyph per letter and an alternative ‘final’ glyph to be displayed only at the end of words or as an isolated shape. This model is what we have implemented in the design of our Mutamathil Taqlidi families of fonts. In that model we combined current Open Type ‘initial’ and ‘medial’ shapes into one ‘normal’ glyph, and the ‘final’ and ‘isolated’ shapes into one ‘final’ glyph.
The main goal of the NAIM model is to eliminate, as much as possible, the negative effects of the current glyph substitution model. Implementing NAIM, particularly when combined with the two-glyph per letter typeface design model, would have significant technological, typographical and most importantly educational impact. Technologically, it would eliminate the excessive complexities of Open Type features and their corresponding software libraries. Typographically, it would make developing Arabetic fonts easier and more economical and as a result expand the production and availability of more fonts, especially non calligraphic fonts. Educationally, it would make learning Arabetic script much easier. New learners would not quit the educational process early due to the many ‘confusing’ shapes needed to be memorized up front. They can instead appreciate learning such optional shapes if they are interested in Arabetic calligraphy later on. Ordinary users would also benefit from editing the resulting static Arabic documents.
To add to this already complex and unpleasant glyph substitution processing of Arabetic scripts on computerized system, another requirement was added: bidirectional ordering or bidi. Despite the the fact that these scripts and their numbering systems are predominately written in a "right to left" order, the bidi requirement was introduced and became the default and only input method because a very small portion of numbers, numbers consisting of more than two digits, are written "partially" in a "left to right" order. Documents of mixed Latin and Arabetic text, despite their importance, do not justify the default bidi requirement. For the sake of an extremely limited case, which should have clearly be addressed through addition of an optional bidi editing feature in applications, users of all Arabetic scripts are forced today to live with the bidi ordering and its annoying visual affects when mixing both numbers or punctuation with text. Moreover, the damaging bidi process did not, and would never be able to, solve the impossible and insolvable problem of numeral writing in Arabetic scripts since numbers are ordered in both directions not only "left to right". In our Java based utility, designed primarily to demonstrate NAIM, we have provided an optional feature that would allow users to compare the look and feel of right to left only ordering with bidi ordering when mixing text, punctuation, and numbers.
Here is how NAIM works. As user keys in a word, the first letter is always displayed in its ‘normal’ (or ‘initial’ shape in a four-glyph per letter model) form, as it naturally should be. The second letter typed would again be displayed in its ‘normal’ form in a two-glyph per letter model, or in its ‘medial’ form in a four-glyph per letter model. As users keep on typing, letters would continue to be displayed in their ‘normal’ (or ‘medial’ in a four-glyph per letter model) forms until a ‘final trigger’ character is keyed, in which case the last glyph typed would be replaced with its ‘final’ shape glyph. A ‘final trigger’character is basically any non Arabetic letter or diacritic character like space, number, punctuation mark or any other application designated character. Implementing NAIM on the font level using Open Type (OT) features is ideal since users would be able to utilize it on any OT enabled application. But unfortunately OT technology lacks several crucial element for NAIM to work correctly on the font level at this time. On this site we have implemented NAIM on the application level using Java technology. This approach proved adequate to demonstrate our method. It furthermore proved that Java, or any other programming platform, can definitely be used to provide users with this important alternative input method, at least as an option, on the today's widely available applications.
Arabetics Implementation of NAIM
We have implemented NAIM both on the font and application levels. On the application or system level, NAIM would work with any commonly available Open Type and Unicode standards conformant Arabetic font and software application. To experience NAIM on the application level, proceed to the font-independent, NAIM enabled, Java applet page. We have also implemented this method on the font level, both two and for glyphs per letter Arabetic font models, by storing logic in the font through Open Type lookup features and utilizing a NAIM aware java applet. NAIM is US Utility Patent pending.