I've been trying to add support for Sanskrit derived languages, but just rendering the characters has halted progress. For the currently supported languages, such as English, Russian, Greek, French, even Japanese, the characters are more or less statically mapped to the unicode (looking at my $font again, I see that Kanji bitmaps are perhaps mapped to unspecified unicode ranges?).
However, in the class of languages for which I am trying to provide support, certain characters are meant to be produced by an ordered combination of other characters. For example, the general sequence in Devanagari script (and this extends to the other scripts as well) is that consonant+virama+consonant produces half-consonant+consonant, where the half-consonant has no other unicode specification. As a concrete case in Devanagari, na virama sa (viz., \u0928\u094d\u0938) should produce the nsa character (this sequence can be seen in any unicode representation of the word "Sanskrit" in Devanagari script). It seems to me that TTF font specifications (i.e., those I converted to subfonts using Federico's ttf2subf) include these sequence definitions, which are then processed by each application providing support for the fonts. Plan 9 subfonts are much too simple for this. So, in this case, what are some ideas towards representing the above? I've thought about a ktrans-alike that perhaps filters the data rio gets and processes it for these sort of things, but it doesn't seem to be the best possible way to proceed. If we can even get past this hurdle, I'd be more than happy to patch ktrans for input support for this class of languages. Thanks, ak
