[smc-devel] Re: [Indic-computing-devel] javascript indic renderer and community portals

[Tapan S. Parikh]

> 
> In a web-based client-server model of app development,
> unlike Latin scripts/languages, it would be more
> appropriate to do input processing, transliteration
> and glyph composition for rendering on the server
> side. 

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.

> A couple of weeks back, I made an enhancement to my
> transliteration library (translib under the
> indic-computing project on sourceforge) to take a
> 'word' in an Indian language encoded as a sequence of
> Unicode characters (in UTF-8 format), kind of map it 
> (using a user-defined lookup mapping file) to the most
> appropriate Roman phonetic input and then apply the
> transliteration rules for that language+script by
> looking up the transliteration rule file. The output,
> as before, is a sequence of symbolic glyph names that
> correspond to glyph indices in a given font file. This
> can be fed to a font reading and rendering library
> such as freetype2 for final display (Koshy wrote a
> python script to do this using gozer, but he is now
> replacing gozer with a python wrapper to ft2).
> 

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?

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)?

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.


> 
> Unicode is neither an input mapping scheme nor a glyph
> mapping scheme; it's just an encoding scheme, as all
> of us know. It has limitations, but with a sound
> transliteration library in place, utf-8 can be used
> for 
> storing Indian language content for further processing
> (search, sort, display etc etc).
> 

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?

Any other views?

-- Tapan