Tamil Discussion archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

> 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.


Home | Main Index | Thread Index