Re: [WMASTERS] Re: glyph choices for font encoding-version 1.2

[nagu@ncms1.cb.lucent.com]

Dear Kalyan,

Pl. read further:

> 
> Dear Nagu:
> Thanks a lot for your prompt response/comments.
> If you have not noticed, the current participants of the font encoding
> scheme discussions also include those in the mailing list 
> "tamilnet@tamilnews.org.sg" of the National Univ. of Singapore
> and the members of the TNC.

Will copy my comments to them too.

> 
> Just a few quick responses to the points you raised:
> i) The suggestions to include the copyright and registered mark signs
> came from Mr. Leong Kok Yong of IRDU unit, NUS, Singapore.
> Prof. Schiffman pointed out that if we add a few of these special
> characters, it would avoid unnecessary changing the font back 
> and forth.

I accept the need for them. Thats the main reason I am asking for
leaving them empty (Not occupying them with some other letter).
Leaving them empty gives the chance for others to put their own
special characters.

> 
> ii) In addition to having the series ik, ing, ic, it,... I have
> included  the 
> "pulli" as a modifier glyph to go with the grantha characters.
> In the present scheme all the uyirmeis of grantha characters are
> generated using the modifiers. Such a scheme would be logical
> and easy to remember during the learning process.
> 
> iii) As you know, early this year we debated a lot on whether or 
> not kerning can be invoked to generate the "uyirmeis"
> Many software developers such as Muthu, Ravi Paul repeatedly
> expressed the desire to have as many uyirmeis as single glyphs
> in the font encoding scheme to ensure high quality print out
> required for prof. publishing houses. I chose to keep ik, ing,... series
> as
> such and invoke kerning only in the ikara and iikara varisai.
> Right kerning often works out well as it involves back-tracking
> a fixed number of pixels, irrespective of the size of the mei
> character (on thin ones like ra as well as wider ones like Na).
> Back-tracking "pulli" to go on top of mei does not work that
> well. You need at least three or four back-tracking pullis to get
> the pulli right at the center/top of the mei.  
> My personal opinion is that such a combined approach would 
> ensure optimization at the same time not loosing on aesthetics.
> Of course there has to be some trade off, since there is no way
> we can have all the 130+ unique tamil alphabets as such in any 
> scheme.

Agreed. Lets have Mey Ezuththukkal. This also means I take back
from my 7-bit Scheme (Am not individually cc-ing this mail to
everybody! :-)).


> 
> iv)  In Mylai I use such a half-kall to get the thuu from thu etc.
> As a right-end modifier such a half-kall should not pose any
> problem in principle. So we can liberate a few more slots in this
> way if necessary. I do not see any abs. necessity now.
> 

Isnt it difficult to stuff those big letters in text terminal
character cells??? Even Muthu and Ravi Paul (who are looking for
Quality Output) too prefer this.


> v) character-encoding vs. font encoding - terminology
> Unless you take for granted "interpreted output", in simple
> fonts, there is a  one-to-one correspondance between the 
> number of keystrokes used and the number of glyphs 
> stored in the output text. When you go for "interpreted
> output" using intelligent softwares, the output does not
> even have to depend on the nature and quality of the
> glyphs stored in the font. We should stick to "direct 
> output" scenario and ensure that we can deliver decent
> output of entire tamil alphabets.

I prefered "character encoding" considering that, in practice, different
fonts can be developed and all of them can be mixed in a same document
with font tag. But what we are doing is giving "code" for collection
of glyphs that particularly make up the characters of Tamil Language.

I agree with sticking to "direct output" and "Better Quality" scenarios
AMAP.

> 
> vi) I kept talking about characters and glyphs because of
> our desire to have the feasibility of storing the tamil text
> generated using these simple 8-bit fonts in the unicode
> format and vice versa.  In the last TamilNet'97 conference
> at Singapore, there were several presentations where
> tamil texts originating from tamil fonts are stored in 
> unicode format. UC Berkeley Library is currently
> looking into this possibility for cataloguing of all non-roman
> language titles. So this is an important issue we have to
> address. It is better we addres this now, if we are talking
> about using the proposed 8-bit font concurrently with
> evolving unicode schemes.

Looks like practically its not possible to have 7-bit character set
without Kerning. And if we have to keep the positions of all the
special characters "~, !, @, # etc.", its really not possible.
(I think I'll cc this mail individually to Muthu....list :-))

> 
> vii) Deciding on whether we go for 
> 7-bit font or 8-bit fonts, 
> with or without diacritical markers,
> with or without old style tamil alphabets, 
> with or without grantha characters
> is a difficult issue, since the choices are more at the
> personal preferences level. 
> Right now we are focussing on the technical aspects
> of agreeing on what can go in a 8-bit polyvalent font.
> Once we finish this and agree on an encoding scheme,
> it will be a trivial issue to drop one or more of the
> possibilities listed above. 
> Even if Tamilnadu Committee goes for the scaled
> down monolingual 7-bit font, it is not obvious whether
> the tamil lovers around the world would agree.
> 
> You will find the following in the summary report of
> discussion panel of the last TamilNet'97 Conference
> held recently in Singapore:
> "The panel agreed that there should be a unified 8-bit
> character set that will co-exist with Unicode for the 
> Tamil language. The TamilNadu Computer Standardization 
> Committee will work with developers towards a unified 
> 8-bit character set. To facilitate the interchange of 
> the myriad of 8-bit codes around, code conversion has 
> to be provided for these codes. The use of Unicode as
> the standard interchange code is proposed to coexist 
> with the unified 8-bit character set for future..."
> 
> The present discussions are purely a follow up of the
> above decision.

Agreed to continue on the same line. Sorry for the deviation!
Just gave it a try :-)

> 
> Kalyan
> 
> 

Thanks for your immediate response.

anbudan,
nagu.