Re: [Indic-computing-devel] javascript indic renderer and community portals
Status: Alpha
Brought to you by:
jkoshy
From: Krishnamurthy N. <kn...@ya...> - 2003-05-13 06:06:56
|
Hi Tapan, --- "Tapan S. Parikh" <ta...@ya...> wrote: > This is debatable (and has been debated). Doing > glyph composition on > the server will preclude user-installed fonts on the > client with > variable glyph sets. Also, depending on how you > define input > processing, it might also preclude different types > of keyboard mappings > (and input methods) on the client side. Yes, it's debatable for more reasons than this. First, as I pointed out and also by Suryaprakash, it can't really be very interactive on the client-side. About user-installed fonts on client side : as we all know, it's not just the fonts that are enough to do rendering for Indian languages - you need to do process the input key sequence according to certain rules, and do or don't do translitration and do the appropriate glyph mapping for 'a given' font, and not any and every font. We all know the issue of lack of any standard for Indian scripts. I guess until we have any standards for Indian script fonts, we can't give full freedom on the client side to choose any font. > Part of this seems like a worthy effort, but the > need for the > transliteration is not clear to me. Why is it > required, what purpose > does the romanized text serve? Why not just go from > UTF-8 directly to the glyph names? Direct mapping of input sequence, whether in utf-8 or Romain phonetic, to an appropriate sequence of glyphs is not feasible for any of the Indian languages, due to the various complexities related to all kinds of contextual details. As I developed the generic transliteration rules framework that would work for any Indian language/script, this had become quite clear to me. Why utf-8 to romanized text : this was more convenient to do this and apply the generic transliteration rules that I developed. > > Its seems that you are proposing now three standards > - Unicode, the > transliteration standard, and the glyph standard > (for storage, > transmission and display respectively). It is > unclear to me why the > storage and transmission standards have to be > different (in fact they > already are - UCS-2 vs. UTF-8). It has been hard > enough to get 1 > standard in place. Why shoot for two more now, when > only one is > required (for glyphs)? No, I am not proposing any new standards. If you have seen the sample fontmaps that give 'symbolic' names to glyphs or cluster of glyphs in a font, and the generic mappings I have given to map the vowels, consonants and other entities of Indian scripts to phonetic keybd input sequences in the transliteration rule map files, I left everything open to the end-user or user of translib. The mappings can freely modified and as long as what's 'stored' is based on an accepted standard such as utf8, that is enough. If at all, we will need a 'minimalistic' glyph standard for each Indian 'script'. > > Also, unless the glyph names are somehow "abstract", > and do not stand > for direct 1-1 mappings to actual glyph indices, > this precludes variable > glyph sets which would be a requirement for > different quality (and cost) > fonts and advanced typography. Yes, glyph names are 'abstract', as defined in the fontmap file format by Koshy. The very precise reason why we developed such abstract glyph names is for usability across different fonts. > > It seems to me you are proposing an alternative to > OTF, which MAY be a > worthy effort if the IPR issues remain muddy w/ that > technology. But > you seem to be doing that at the expense of some of > the complexity and > expressivity of the OTF standard. IMHO that may not > be a wise long term > compromise. Am I missing the point? It's not that I am proposing an alternative to OTF. It's just that I see that with a few special mapping rules for special 'input sequence combinations', we can use special glyphs or clusters of glyphs for effective high quality rendering (e.g in the CDAC Devanagari font, there are four different glyphs for dependent vowel sign 'i' and it takes just four simple rules in the translit. rule file (simple text file) to effectively specify the context where each of these four different glyphs need to be used). cheers, Nagarajan __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |