- To: tamilnet@tamilnews.org,webmasters@tamil.net
- Subject: Character to Glyph and Software Gimicks
- From: "Muthu Nedumaran" <MNEDUMAR.SG.ORACLE.COM>
- Date: 12 Sep 97 11:17:48
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset="us-ascii"
>I already posted my clarification on diacritical markers so I will
>not repeat them here. I fully agree with Muthu that using
>translators/convertors one can always go back between tamil
>script text and a romanized text. My preferences are going for
>a general /comprehensive truetype font that can directly implement
> input in both formats without the need for any additional
>software gimmicks.
Kalyan and friends,
My proposal to have Tamil etext saved in just one format and
rendered in multiple forms seems to have caused some stir. For the
benefits of all (and those who wrote to me outside the list for
explanation), I'd like to present some details here - there are
*no* software gimicks :-)
*If you are already familiar with the arguments, please skip this
message - it's a repetition with some details*
1. I'm suggesting that the character set we encode only includes
characters that we use in modern day Tamil. With the modifiers,
and granthas (for those who argue against grantha - just don't
see this word for now - the discussion and logic is still valid)
We pretty much have this already in Kalyan's GIF. We may just
need to work on the order.
Having this set of characters, we can render Tamil with *any*
kind of font. It's a plain character to glyph mapping we are
all used to. We can even do this in ASCII terminals (without
the need to manufacture one for Tamil).
I think this is well understood.
2. Old-Style-Tamil.
I am 100% for keeping this. At least to say that tamil used
to be written this way ..... But it may not be a good idea to
*encode* characters to represent this into the character set.
(I've spoken enough on the implications so I'll save some
bandwidth here.)
It is my understanding that OpenType is quickly emerging as a
unified (TrueType + Type 1 + New technology) font format for
graphical desktops : NT already has it, Win95 will, MacOS will
and Java will => this is almost 100% of the desktops on the
planet.
Without any software gimick, one will be able to construct a
glyph substitution table in OpenType fonts. (I'm dieing to
get home - since I do have an RFC that talks in excruciating
detail on how this works). For instance, lai appears in the
text as kaiyakaram (the modifier for ai-kaarams) followed by
la. You can tell the font to replace the kaiyakaram with the
vaathu symbol everytime the font sees it before la, na, Na or
La. The same for old style Na, na and Ra - everytime a kaal
follows a na, Na or Ra, replace both that with the corresponding
glyph.
So there you go !.
Now imagine a scenario : Mr. A has stored all his etext based
on this new character set. Mr. B has two OpenType fonts, one
with a glyph subs table and one without. He will be able to
read the pages with both the fonts. One renders in new-style
and the other renders in old-style - don't you think this is a
bravo !
The technology that does glyph substitution is pretty much
similar to pair-wise kerning that we are familiar with. Again
*no* software gimicks. Just need to learn something new :-)
3. Transliterated Tamil
Transliterated Tamil can be rendered the same way as old style
Tamil - but this is a little tricky and will greatly depend on
how we implement transliteration. If it's a one on one maping
of each Tamil aphabet (i.e. we write ten as 'paththu' or 'pattu'),
than it's straight forward and the above method can be used.
Now, imagine, Tamil text saved in one format, rendered in three
different variants : modern, old-style, transliterated. All by
just substituting a font !
Friends, the point I'm trying to make here is - by restricting the
*encoding* of the character set to just one set - i.e. the set that
we use in our daily work, we will have the benefit of keeping tamil
electronic text in a single unified format. Wembasters, archive
managers, software developers and font developers will love this :-).
Sorry to pound this again and again - but I'd like to hear arguments
on this system. Question is *not* if we have enough space to stuff
glyphs in - but in how we are going to *manage* what gets produced
out of it. Which is why we should work on the *science* of what goes
in rather than the *art* of producing text :-)
anbudan,
~ MUTHU