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

[Krishnamurthy Nagarajan]

Hi Tapan,

--- "Tapan S. Parikh" <address@hidden> 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