Bringing focus back to Arabetic scripts users, we have introduced an alternative text input method to the prevailing and only method available today: shaping. Our new 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 our Mutamathil type style's two glyphs per letter model but can be implemented in today’s widely used four glyphs per letter model as well. The two glyphs per letter model in Mutamathil consists of one unique ‘normal’ glyph per each letter and an alternative ‘final’ glyph to be displayed only at the end of words or as an isolated shape, for certain letters. This model is what we have implemented in the design of our Mutamathil Taqlidi families of fonts, where we combined Open Type ‘initial’ and ‘medial’ shapes into one ‘normal’ glyph, and the ‘final’ and ‘isolated’ shapes into one ‘final’ glyph.
The main goal of NAIM is to eliminate, as much as possible, the negative effects of the current glyph substitution model, or the so-called shaping. Implementing NAIM would have significant technological, typographical and most importantly educational impact. Technologically, it would simplify Open Type features and their corresponding software libraries. Typographically, it would make developing Arabetic fonts easier and more economical and as a result expand production and availability of fonts, especially non calligraphic fonts. Educationally, it would make learning Arabetic script much easier specially for those using computer software. These learners would not quit early due to the many ‘confusing’ shapes needed to be memorized up front. Finally, for ordinary word processing users, NAIM, would make their editing process a much pleasing one.
Adding to an already complex and unpleasant process of glyphs substitutions, dealing with Arabetic scripts on computerized systems had introduced another complex requirement: bidirectional ordering or bidi. Despite the fact that Arabetic scripts and their numeral systems are mainly written in a "right to left" order, today's software vendors made bidi ordering requirement the default and only input method available to users, in order to deal with the few cases where numbers consisting two digits or more would need to be written partially in a "left to right" order. Mixing Latin with Arabetic text in documents, despite its importance, does not justify forcing bidi as a default requirement in Arabetic word processing software. For the sake of extremely limited cases, which could have been addressed through an optional bidi editing feature in software applications, users of Arabetic scripts are forced to live today with the bidi ordering process and its annoying visual affects. Moreover, this bidi process had not solved the insolvable problem of dealing with bidi Arabetic numerals since inputting numerals is both "right to left" and "left to right." NAIM addresses both glyph substitution and bidi ordering. 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 an alternative to shaping. 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 as an application-independent (or font-dependent) solution and as an application-dependent (or font-independent) solution. On an application or font-independent level, NAIM would work with any Open Type and Unicode standards conformant Arabetic font and software application. As a font-dependent solution, NAIM was implemented for both two and four glyphs per letter fonts by storing logic in fonts using Open Type lookup features and a NAIM-aware java applet.
To experience NAIM on an application level, proceed to our font-independent, NAIM enabled, Java applet page. NAIM is US Utility Patent pending.