Where is the source code ?
The source code for the editor is available under the GPL v2. You can download the source and binaries from the Downloads page of the editor.
What scripts are currently supported?
Apart from English, the editor currently supports the following Indian languages :
- Asamiya (Assamese)
- Bangla (Bengali)
- Devanagari (for Hindi, Sanskrit, and Marathi)
What about other scripts?
A separate editor for Urdu is currently under development, and a beta should be available sometime in October, 2007. While there are plans to add support for Malayalam, and Gurmukhi we do not have an ETA.
As for other languages, in theory, any language that follows a syllabic writing system can be supported by the IMLI framework, and hence, the editor. We use a set of syllables from Indo-Aryan, and Dravidian languages to support the languages listed above, and it is straightforward to support older scripts such as Brahmi, Granth, and Modi. With the same approach, South Asian scripts such as Sinhala, Bali, Tibetan, Burmese can also be handled.
Can the editor support other Indian Language fonts?
Short Answer : Yes.
Long Answer : The IMLI framework can work with most 8-bit TrueType fonts, as well as Unicode fonts that have been in use for different Indian scripts. To use these fonts, one will have to provide the font and a mapping table (entries for Unicode are in UTF-8). The mapping table has to be generated individually for each font. For example, the editor uses free fonts from multiple vendors / sources and separate tables are required for each vendor. Look under the Technology page for more information.
What is special about the IMLI project ?
The encoding scheme allows text to be represented in terms of syllables (aksharas). This is consistent with the writing systems followed in India, which are syllabic in nature. This approach separates the content and it processing from the presentation. In MVC terms, IMLI provides the Model, and enables building powerful Controllers.
What is the file format used by Acharya ?
The application uses ISCII (7-bit) as its standard format. It can export Unicode text. The library uses a 2-byte code to store syllables. The 2 bytes are split into 6 bits for the consonant, 6 bits for the conjunct, and 4 bits for the vowel. The data is stored in little endian format. This is discussed in detail in the Technology page.
Why not use Unicode instead of the 2-byte code ?
Unicode emphasizes the script and not the language. Consequently, it has a bias towards the rendering of text. A coding scheme with a bias towards display leads to a lot of complexity in text or linguistic processing. In respect of Indian languages, text processing is easier done at the syllable level. Unicode for Indian scripts uses multiple codes for a syllable and one may have text rendering information as part of the code string (a ZWNJ, for example). Also, processing multiple bytes (MBCS) for rendering text is quite complex.
An application based on Unicode is expected to code into itself the manner in which text will be rendered. This requirement stems from the observation that the rules of the writing system are not rigid. Consequently, the developer of the application is required to have knowledge of the writing system and its intricacies. This is a difficult condition to meet. Basically, one does not have a Unicode text string display API for Indian scripts that works uniformly across platforms. Applications are therefore dependent on the script. Writing applications which work uniformly across scripts is hence, ruled out. This page has a detailed presentation of all related issues.
Does the editor support word processing / text formatting ?
Think of the editor as a local language Notepad / Gedit. The idea being simple text entry. Currently, there are no plans to add word processing features to the editor. If an immediate for this need exists, you can export RTF text from the editor, which can be imported into a full fledged word processing application such as OpenOffice.org.
What about Dictionaries and Spell Check ?
The current build support dictionaries, which are extensible by the user. Spell Check functionality is not planned at present.