In our Bijoy Bangla Software, in fact we do not have 9 vowels in the code and keyboard(o and oo is the exception as that two character does not have vowel signs). When someone input the characters as per Bijoy keyboard they enter Hasanta and the vowel sign and in Unicode that two characters are saved. Gor Ki it is Ka+Ekar but for Koi, it is Ka+Hasanta+Ekar. When someone enters conjuncts Hasanta is in the middle. If we talk about reducing the codes, we can do that. We do not need two codes for vowel and vowel signs. Unfortunately basis characters like Khanda ta, Antostho Ba, Danrhi, Dui Danrhi has not been coded, whereas we got two codes for one characters-say for vowels. If we leave the shaping of characters to the rendering engine do we need those 9 codes? In reality we are also confined to the input method. As all the coded characters can not be accomodated in the keyboard we shall have to use Hasanta as the link. Mustafa Jabbar ------------- Original message follows -------------
On Tuesday 07 October 2003 12:21, Gautam Sengupta wrote: > Is there any reason (apart from trying to be > ISCII-conformant) why the Bangla word /ki/ "what" > cannot be encoded as [KA][ZWJ][I]? Do we really need > combining forms of vowels to encode Indian scripts? I don't know what the original motivations were, but one thing about the current (ISCII-based) encoding scheme that appeals to me is that on average it requires fewer characters than other more natural schemes. Bangla has a high percentage of 'vowel signs', each of which would require two characters in your scheme as opposed to one in the current one. > Also, why not use [CONS][ZWJ][CONS] instead of > [CONS][VIRAMA][CONS]? One could then use [VIRAMA] only > where it is explicit/visible. But this would not reflect the fact that the *glyph* [CONS][ZWJ][CONS] is actually the same thing as the *sequence of characters* [CONS][VIRAMA] [CONS], i.e., [CONS][VIRAMA][ZWNJ][CONS] is also a perfectly legitimate representation. This latter decision is one that should be taken (normally) by the rendering mechanism (loosely speaking, the font), not the author. Deepayan
