The following message sounds very serious. I'm sure many of you would have
read it at tamilinix. But I'm posting this so that we itemise this as
another problem to be fixed.

Sinnathurai Srivas

<<<
Subj:  [tamilinix] TSCII and gettext/iconv
Date: 10/3/01 3:38:05 PM GMT Daylight Time
From: n_dinesh@... (Dinesh Nadarajah)
Reply-to: tamilinix@yahoogroups.com
To: tamilinix@yahoogroups.com, tscii@yahoogroups.com, infitt@yahoogroups.com

Hi:

In the past few days I have been trying to get the display of my
messages to work on the linux system and based on numerous newgroup
responses and conversations I believe we have to address in some
urgency the issues here. I am attaching an email from a gentle from
MandrakeSoft also.

Here is what I did. I composed my messages as iso-8859-1 compliant and
compiled the messages. When I set my locale to ta_IN (which is what the
loacle is now for tamil), it expects the encoding to be in TSCII-0
encoding.

When I set my locale to en_GB, it displayed most of the messages but
many characters were missing - iso8859-1 does not permit characters in
a range and hence gettext/iconv does not convert them.

I would liek you to read the below attached email and would liek to
hear some thoughts on this. If TSCII is going to be revised, then we
must make sure that a fully suported system is put into future linux
distributions (rather than hacks). We must also consider putting TAB in
so that people would be able to use locales as ta_IN.TSCII-0 or
ta_IN.TAB.

Thoughts,

-Dinesh

Here is the email from Mandrake. Lines with '>' are my initial
observations.


>I am trying to understand some behaviors under Mandrake 8.0 and would
like
>to someone to shed some light on this.
>
>I am currently translating files and loaded them into Mandrake 8.0.
My .i18n
>file has the setting LANG=ta_IN and LANGUAGE=ta_IN. Mymessages are
encoded
>as iso-8859-1.

You probably mean in tscii-0 encoding ?

>I compiled my messages into /usr/share/locale/ta/LC_MESSAGES/
directory. The
>system picks up the locale but what I see on the screen does not
correspond
>to the translation and does not make sense either. Seems like a
random
>character display.

gettext() calls iconv() to do automatic charset translation between the
charset of the po file and the charset of the user.
There are two problems in your case:
1. you declare a wrong charset in the po file (iso-8859-1 doesn't allow
to write Tamil)
2. the tscii support in iconv of 8.0 is broken (only half of the
letters are
   supported; I removed it in 8.1 it was a bad idea of myne to include
   such a broken one...)

I suggest you put in the charset= line of po files the same thing that
a "locales charmap" returns in command line; that way gettext won't do
charset ocnversion. If that still doesn't work, then remove the tag the
whole
header as "fuzzy", then gettext won't do charset conversion for sure,
as it
won't have any charset info.

>So I copied the messages into the en_GB directory and set my locale
to
>en_GB. And the messages were displayed to a certain extent , but a
few (10)
>characters were not being displayed.

Problem is that iso-8859-* encodings don't use any char in the
0x80-0x9f
range; probably gettext or some high level function is requesting the
libc
which chars are displayable and which are not.
Or maybe the problem comes from XFree definition of iso8859-1

>Now I moved the messages into the 'da' directory (which should also
be using
>iso-8859-1) and set my locale to da_DK. Again the messages were
displayed OK
>but again a few characters were missing. But this time it was not
same
>characters as in the case of en_GB.

ah? this very strange...
can you send me a po file showing that behaviour so I can test?

>What is going on here? Ta_IN translation started of by using a coding
called
>TSCII-0 which is the same as iso-8859-x (8 bit).

No, it is not the same, only the ascii portion is common; all the rest
is different, tscii-0 doesn't even respect iso-8859-* guidelines (no
chars
in 0x80-0x9f range, no combining chars) so it won't ever be an
iso-8859-*
encoding.
It is an 8bit encoding, but using the whole 8th bit range, more like
the DOS/Windows encodings.

Another thing is that tscii-0 is a glyph encoding, not a char encoding;
it is not a transposition of unicode, as conversion of tscii-0 to/from
unicode requires complex many-to-many byte conversion (while all other
8bit encodings are one-to-one with unicode chars).
That is the reason why it isn't supported yet; I have added to glibc
support
for several other 8bit encodings, but it was easy for them, just a
single table, just to create a file in the same format than the ones
in /usr/share/i18n/encodings/;
but for tscii-0 it requires building a real *.so shared lib with real
code,
and I don't know the internals of the libc well enough.

There is an X11 XLC_LOCALE fiel for tscii-0; but it requires you use
fonts naled *-tscii-0, if yours are named *-iso8859-1 try changing
their
name (or making some aliases) and try again with ta_IN locale;
if that still doesn't work, try to edit the file
/usr/X11R6/lib/X11/locale/locale.dir
to change the line

tscii-0/XLC_LOCALE:     ta_IN.TSCII-0

to

iso8859-1/XLC_LOCALE:     ta_IN.TSCII-0

but then you will need to name your fonts *-iso8859-1.

If that still doesn't work, try changing that line to:

koi8-k/XLC_LOCALE:     ta_IN.TSCII-0

(or any other complete 8bit encoding; the advantage of koi8-k is that
it is unlikely there will be real koi8-k fonts around)
and of course rename your fonts as *-koi8-k in such case.

>But I am not sure what it
>is doing though? It should just display and let the font take care of
the
>rest.

It's more complex than that, as more and more unicode is being used
internally; withotu a proper tscii-0 <-> unicode conversion the use
of tscii-0 will be more and more a problem.

Note also that someone made a patch to XFree86 that allows support for
all indic languages using unicode as the encoding; the patch is not yet
released, but as soon as it will be done we will made an rpm package
for
Cooker, it will then be possible (having the proper OpenType fonts) to
display in X11 Tamil, Hindi, Kannada, etc.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

I request the group to test the keyman keyboard. for
1.7. so that we can prepare a document for all the
problem...

Regards,
Jayaradha

--- "K. Kalyanasundaram" <kalyan@...> wrote:
> Dear Kumar:
>
> First an appeal. Please confine all discussions on
> TSCII revisions
> to a single list, this one <tscii@yahoogroups.com>
> so that the
> postings are not scattered.  Those who are
> subscribed to this list
> should be directed to contact moderator of this list
> Manivannan <mmanivannan@...> to enable
> their subscription.
>
> > It is the time we should critically look into the
> problems.
> > I have seen reports of missing ¬ (A), the second
> uyir in
> > many situations. Although the word break problem
> with "thu" is
> > not a serious issue, it have to looked into as
> well.
>
> Can you please be more specific in describing the
> actual problem
> if any with the second uyir letter "A/aa" ( citing
> the application,
> software, platform, specific examples etc) ?
>
> > In this regard, working toward a better solution
> (TSCII 2.0),
> > may be we should open up the discussions in
> detail.
> >
> > I fully agree with an interim TSCII 1.7 soultion.
>
> Font encodings are very basic standards and we
> cannot afford
> to engage in revisions every now and then. There
> should be
> (will be?) only a single revision of TSCII for
> several years
> to come.
>
> If all known/existing problems with TSCII are
> documented now,
> then it will be easier to decide if the revision
> should be at
> the level of 1.7 or 2.0.
>
> If I may, I would like to propose a deadline for our
> discussions:
>
> end of Oct 2001 : round up discussions and agreement
> on the
> actual conent of revised TSCII (1.7 or 2.0)
>
> end of nov 2001 : distribution of relevant font
> faces, text editors,
>   text convertors and end of field-testing of
> revised TSCII on all
>   possible application scenarios
>
> 1 Jan 2002 onwards:  All TSCII usage on the Net be
> on the proposed
>   revised TSCII scheme ONLY ;-)
>
> Kalyan
>
> PS: a point of clarification on the recent posting
> of Muguntharaj.
> only a single proposal A is on the table as regards
> to 1.7.
>
>


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

Kalyan,

You're right - we never designated any "private use area" in TSCII.  The
issue was brought up during the discussions but we pushed it aside to avoid
incompatibilities as vendors/developers may use a symbol in that space that
may not be available in other TSCII fonts.

~ MUTHU

----- Original Message -----
From: "K. Kalyanasundaram" <kalyan@...>
To: <tscii@yahoogroups.com>
Sent: Tuesday, October 02, 2001 2:31 AM
Subject: Re: [tscii] New file uploaded to tscii


> Dear Sinnathurai:
>
> > The slots showing Tamil numerals are a kind of private use area. The JPG
> > description does not adhere to this practice. Could you clarify.
> >
> > Sinnathurai
> >
>
> As far as I know, the Tamil numerals have been integral part of the TSCII
> version 1.6, put in there to provide compatibility with Unicode. And
> these will remain as such in the proposed 1.7 revision. Those rows 8-9
> slots were never designated as "private use area" in TSCII discussions
> that I am aware of.
>
> In view of the controversies on whether or not it is safe to use
> slots 128-159, some of the developers did not include Tamil numeral
> glyphs in their font-faces.
>
> I am not sure on what the planned uses for such a "private use area".
> There have been proposals that we should go for a separate ding-bat type
> special symbols font encoding for Tamil needs. Such an additional Tamil
> symbols font can be used along with both TSCII and TAB. IMHO, this could
> be a more meaningful consistent approach than to let each developer to
> put in his/her symbols glyphs wherever they choose.
>
> Kalyan
>
>
>
> To unsubscribe from this group, send an email to:
> tscii-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Dear Kalyan,

The Tamil numerals were discussed and it was agreed to keep these slots for
numerals and other purposes. With this understanding I published
TamilAvarangalTSC. This has been used for Tamil research purposes and
presently to investigate UTF-8.

I made a similar representation to TAB and beleive that TAB also treats some
slots as near private use.

I think there is lot to gain from defining as private use with some guide
lines, than defining for numerals only.

Sinnathurai


>From: "K. Kalyanasundaram" <kalyan@...>
>Reply-To: tscii@yahoogroups.com
>To: tscii@yahoogroups.com
>Subject: Re: [tscii] New file uploaded to tscii
>Date: Tue, 02 Oct 2001 11:31:50 +0200
>
>Dear Sinnathurai:
>
> > The slots showing Tamil numerals are a kind of private use area. The JPG
> > description does not adhere to this practice. Could you clarify.
> >
> > Sinnathurai
> >
>
>As far as I know, the Tamil numerals have been integral part of the TSCII
>version 1.6, put in there to provide compatibility with Unicode. And
>these will remain as such in the proposed 1.7 revision. Those rows 8-9
>slots were never designated as "private use area" in TSCII discussions
>that I am aware of.
>
>In view of the controversies on whether or not it is safe to use
>slots 128-159, some of the developers did not include Tamil numeral
>glyphs in their font-faces.
>
>I am not sure on what the planned uses for such a "private use area".
>There have been proposals that we should go for a separate ding-bat type
>special symbols font encoding for Tamil needs. Such an additional Tamil
>symbols font can be used along with both TSCII and TAB. IMHO, this could
>be a more meaningful consistent approach than to let each developer to
>put in his/her symbols glyphs wherever they choose.
>
>Kalyan
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Dear Sinnathurai:

> The slots showing Tamil numerals are a kind of private use area. The JPG
> description does not adhere to this practice. Could you clarify.
>
> Sinnathurai
>

As far as I know, the Tamil numerals have been integral part of the TSCII
version 1.6, put in there to provide compatibility with Unicode. And
these will remain as such in the proposed 1.7 revision. Those rows 8-9
slots were never designated as "private use area" in TSCII discussions
that I am aware of.

In view of the controversies on whether or not it is safe to use
slots 128-159, some of the developers did not include Tamil numeral
glyphs in their font-faces.

I am not sure on what the planned uses for such a "private use area".
There have been proposals that we should go for a separate ding-bat type
special symbols font encoding for Tamil needs. Such an additional Tamil
symbols font can be used along with both TSCII and TAB. IMHO, this could
be a more meaningful consistent approach than to let each developer to
put in his/her symbols glyphs wherever they choose.

Kalyan

There is a problem with cut/copy and paste (in windows).

If we do a proper test of cut/copy and paste (of words, paragraphs, other
combinations) we may pinpoint which characters are causing problems.I think
the A/aa problem is related to this. This is a more critical problem than
the "I" problem.

Sinnathurai


>From: "K. Kalyanasundaram" <kalyan@...>
>Reply-To: tscii@yahoogroups.com
>To: tscii@yahoogroups.com
>Subject: Re: [tscii] Re: [tamilcomputing] Revision of TSCII encoding
>Date: Mon, 01 Oct 2001 17:54:18 +0200
>
>Dear Kumar:
>
>First an appeal. Please confine all discussions on TSCII revisions
>to a single list, this one <tscii@yahoogroups.com> so that the
>postings are not scattered.  Those who are subscribed to this list
>should be directed to contact moderator of this list
>Manivannan <mmanivannan@...> to enable their subscription.
>
> > It is the time we should critically look into the problems.
> > I have seen reports of missing  (A), the second uyir in
> > many situations. Although the word break problem with "thu" is
> > not a serious issue, it have to looked into as well.
>
>Can you please be more specific in describing the actual problem
>if any with the second uyir letter "A/aa" ( citing the application,
>software, platform, specific examples etc) ?
>
> > In this regard, working toward a better solution (TSCII 2.0),
> > may be we should open up the discussions in detail.
> >
> > I fully agree with an interim TSCII 1.7 soultion.
>
>Font encodings are very basic standards and we cannot afford
>to engage in revisions every now and then. There should be
>(will be?) only a single revision of TSCII for several years
>to come.
>
>If all known/existing problems with TSCII are documented now,
>then it will be easier to decide if the revision should be at
>the level of 1.7 or 2.0.
>
>If I may, I would like to propose a deadline for our discussions:
>
>end of Oct 2001 : round up discussions and agreement on the
>actual conent of revised TSCII (1.7 or 2.0)
>
>end of nov 2001 : distribution of relevant font faces, text editors,
>   text convertors and end of field-testing of revised TSCII on all
>   possible application scenarios
>
>1 Jan 2002 onwards:  All TSCII usage on the Net be on the proposed
>   revised TSCII scheme ONLY ;-)
>
>Kalyan
>
>PS: a point of clarification on the recent posting of Muguntharaj.
>only a single proposal A is on the table as regards to 1.7.
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

The slots showing Tamil numerals are a kind of private use area. The JPG
description does not adhere to this practice. Could you clarify.

Sinnathurai


>From: <tscii@yahoogroups.com>
>Reply-To: tscii@yahoogroups.com
>To: tscii@yahoogroups.com
>Subject: [tscii] New file uploaded to tscii
>Date: 1 Oct 2001 14:58:53 -0000
>
>
>Hello,
>
>This email message is a notification to let you know that
>a file has been uploaded to the Files area of the tscii
>group.
>
>   File        : /charset17_a.gif
>   Uploaded by : mugunthraj@...
>   Description : "Proposal A " - for  TSCII 1.7 - This file shows the
>proposal A, ie the 'e' character is retained in the slot 173 for backward
>compatibility and it is added to the Slot 254.
>
>You can access this file at the URL
>
>http://groups.yahoo.com/group/tscii/files/charset17_a.gif
>
>To learn more about file sharing for your group, please visit
>
>http://help.yahoo.com/help/us/groups/files
>
>Regards,
>
>mugunthraj@...
>
>
>
>
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Dear Friends:

> First an appeal. Please confine all discussions on TSCII revisions
> to a single list, this one <tscii@y...> so that the
> postings are not scattered.  Those who are subscribed to this list
> should be directed to contact moderator of this list
> Manivannan <mmanivannan@e...> to enable their subscription.

A small correction on the second line. It should read: "Those who
are interested to participate in (or simply follow up) TSCII revision
discussions should be directed to contact moderator of this list
Mr. Manivannan <mmanivannan@...> to enable their
subscription.

sorry for the errors.

Kalyan

Dear Kalyan ,
Thanks for pointing this out.
The file for proposal B, is removed from the egroups
page.
The file "charset17_a.gif" which represents the
proposed encoding as of now,is kept in the egroups
page. If any other changes are proposed, let us update
this file accordingly.

Thanks for coming out with a time table for the
standards revision.

Anbudan,
Mugunth
Tamil Innaiya Erumbugal
www.tamil.net/newtamil

>
> PS: a point of clarification on the recent posting
> of Muguntharaj.
> only a single proposal A is on the table as regards
> to 1.7.
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> tscii-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

Dear Kumar:

First an appeal. Please confine all discussions on TSCII revisions
to a single list, this one <tscii@yahoogroups.com> so that the
postings are not scattered.  Those who are subscribed to this list
should be directed to contact moderator of this list
Manivannan <mmanivannan@...> to enable their subscription.

> It is the time we should critically look into the problems.
> I have seen reports of missing ¬ (A), the second uyir in
> many situations. Although the word break problem with "thu" is
> not a serious issue, it have to looked into as well.

Can you please be more specific in describing the actual problem
if any with the second uyir letter "A/aa" ( citing the application,
software, platform, specific examples etc) ?

> In this regard, working toward a better solution (TSCII 2.0),
> may be we should open up the discussions in detail.
>
> I fully agree with an interim TSCII 1.7 soultion.

Font encodings are very basic standards and we cannot afford
to engage in revisions every now and then. There should be
(will be?) only a single revision of TSCII for several years
to come.

If all known/existing problems with TSCII are documented now,
then it will be easier to decide if the revision should be at
the level of 1.7 or 2.0.

If I may, I would like to propose a deadline for our discussions:

end of Oct 2001 : round up discussions and agreement on the
actual conent of revised TSCII (1.7 or 2.0)

end of nov 2001 : distribution of relevant font faces, text editors,
   text convertors and end of field-testing of revised TSCII on all
   possible application scenarios

1 Jan 2002 onwards:  All TSCII usage on the Net be on the proposed
   revised TSCII scheme ONLY ;-)

Kalyan

PS: a point of clarification on the recent posting of Muguntharaj.
only a single proposal A is on the table as regards to 1.7.

Dear TSCII group members,
Based on the mails sent by Sivaraj and kalyan,  My understanding is that:
1. We are going to agree upon a interim standard 1.7 for existing 'e'
problem.
2. There are two encoding schemes proposed for the TSCII 1.7

1. Proposal A.
Having the 'e' character  in the currently vacant slot  254 and leaving
the 'e' character in the existing slot 173 also for backward compatibility.
Please view the gif file "charset17_a.gif" uploaded in the tscii egroups
page.

2. Proposal B.
Moving the 'e' character from the existing 173 slot to 254 slot and having
the slot 173 vacant.


I favour the proposal A for the obvious reason that it has backward
compatibility and i foresee no problems in having the 'e' character in 173
as deprecated glyph as Sivaraj has pointed out.
I have also made a test font "TSCtest1.ttf" and a keyman5.0 file for using
this font and uploaded it in the egroups web page.
Please test it out and see the results.

We now know the problem . And we also have two solutions ready at hand. It
is a question of agreeing on any one of them.
Please give your opinions and let us arrive at a conclussion fast.

Delaying this further will be very very damaging to the Tamil computing
field. As the TSCII users ( Windows users) are very much annoyed at the 'e'
problem and may cease to use any tamil script at all due to this  or they
may use their own encoding and font.
(I my self have experienced this .. as I could not convince anybody to
change their web site to use TSCII as the 'e' problem stares in my face
directly )

Anbudan
Viraivil oru theervai ethinoki irukkum pala thamizharkalil oruvan.
S.Muguntharaj

Tamil Innaiya Erumbugal.
www.tamil.net/newtamil

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the tscii
group.

   File        : /charset17_b.gif
   Uploaded by : mugunthraj@...
   Description : "Proposal B " - for TSCII 1.7 - This file shows the proposal B,
ie the 'e' character is REMOVED from the slot 173 and it is moved to the Slot
254.  Slot 173 is kept vacant.

You can access this file at the URL

http://groups.yahoo.com/group/tscii/files/charset17_b.gif

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mugunthraj@...

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the tscii
group.

   File        : /charset17_a.gif
   Uploaded by : mugunthraj@...
   Description : "Proposal A " - for  TSCII 1.7 - This file shows the proposal A,
ie the 'e' character is retained in the slot 173 for backward compatibility and
it is added to the Slot 254.

You can access this file at the URL

http://groups.yahoo.com/group/tscii/files/charset17_a.gif

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mugunthraj@...

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the tscii
group.

   File        : /tsc17anjal.kmx
   Uploaded by : mugunthraj@...
   Description : Keyman 5.0 file for testing out the proposed TSCII 1.7 standard.
A complete installation exe for the keyman 5.0 (with TSCII 1.7 keymap file and
testfont)file can be downloaded from the URL:
http://www.geocities.com/mugunthraj/tsc17setup.zip for testing.

You can access this file at the URL

http://groups.yahoo.com/group/tscii/files/tsc17anjal.kmx

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mugunthraj@...

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the tscii
group.

   File        : /TSCTest1.ttf
   Uploaded by : mugunthraj@...
   Description : A test font  made in accordance with the proposed TSCII 1.7 with
'e' character placed in slot 254

You can access this file at the URL

http://groups.yahoo.com/group/tscii/files/TSCTest1.ttf

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mugunthraj@...

Dear kumar and other TSCII group members,
It really great that we have started the discussions
on correcting the TSCII problem.
In fact we at erumbugal group have indeed have already
were thinking in the similar lines and have come out
with the surprisingly same solution!!!..
ie.
1. placing the e character in 254 slot
2. retaining the e character in 173 for backward
compatibility.

we have made a font by name test1tsc.ttf and also made
keyman5.0 file and been testing that.. Now I am
sendind the same font file with name changed to
TSCtest1.ttf in accordance with the naming convention
proposed by Sivaraj.
Please test this and give your suggestions.

Anbudan.
S.Muguntharaj
Thamil Innaiya Erumbugal
<http://www.tamil.net/newtamil>


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

--- In tscii@y..., Kumar Mallikarjunan <kumar@v...> wrote:
<cut>
> I fully agree with an interim TSCII 1.7 soultion.
>
> If we all agree with this, I will send Keyman 5.0 keyboard files
> to all of you to test.  I just have them made today.

Kumar, we can upload the test files in the Files section
of 'tscii' Yahoo! Groups.  This way it will be easily
accessible to all.

-Sivaraj.

Sivaraj:

It is the time we should critically look into the problems.
I have seen reports of missing ¬ (A), the second uyir in
many situations. Although the word break problem with "thu" is
not a serious issue, it have to looked into as well.
In this regard, working toward a better solution (TSCII 2.0),
may be we should open up the discussions in detail.

I fully agree with an interim TSCII 1.7 soultion.

If we all agree with this, I will send Keyman 5.0 keyboard files
to all of you to test.  I just have them made today.

Kumar.

At 9/28/2001 08:19 PM +0000, Sivaraj D wrote:
>Dear Friends:
>
>One of the important decisions of INFITT announced at TI2001
>conference was recognition of TAB and TSCII as the two most
>widely used 8-bit bilingual glyph encodings on the Net and
>recommendation that these two encodings alone be used from now
>on in all Tamil information interchange through the Net
>(TAM recommended for cases where monolingual encoding usage
>is deemed necessary).
>
>It was also suggested during the meetings that, if there are
>any problems being faced in the existing encodings, the people
>with experience in those encodings may discuss those problems
>and suggest backward compatible changes to those encodings.
>
>It is time now for people involved in TSCII efforts to engage
>in discussions as to whether TSCII in the present form,
>version 1.6 (for details see the gif at
>         http://www.geocities.com/Athens/5180/charset16.gif )
>is adequate for all our needs or should be revised.
>
>
>TSCII mailing list and TSCII website
>
>Discussions on TSCII revision will take place from now on in
>the mailing list <tscii@yahoogroups.com>. This will be the
>last posting on this topic copied to all Tamil mailing lists.
>
>Archives of the list <tscii@yahoogroups.com> will be open for
>all those interested to follow the discussions (currently
>archive open only to members but this will be changed).
>Those interested to participate in the TSCII revision
>discussions should sign up by visiting yahoo site
>   http://groups.yahoo.com/group/tscii/
>
>We now have the domain name <www.tscii.org> registered and
>this site will be used to provide all information related to
>TSCII encoding.  Existing site <www.tamil.net/tscii> will
>continue as a mirror site.
>
>
>Problems of TSCII encoding
>
>TSCII has been in use widely for nearly four years without
>major problems in several modes of information interchange
>such as emails, mailing lists, websites, pdf files and desktop
>publishing in three major computer platforms (windows,
>macintosh and unix).
>
>One persistent problem noticed during the past two years is
>handling of third uyir letter "i" (encoded slot # 173) in some
>of the key Microsoft application softwares running under
>Windows OS (e.g. Internet Explorer, Outlook Express and MS Word).
>Even today Sun Star Office package of Win OS handles TSCII
>cleanly. The above problem is due to over-riding of "i" at the
>unprotected slot (#173) of soft-hyphen of win-1252/ANSI schemes.
>
>One other documented problem noted is bad word-break that occurs
>(right after the uyirmei letter "thu" when Tamil Texts are used
>in justified format during DTP publishing in MS-Word and related
>softwares. This is the outcome of using shrink-wrap softwares
>created for English (Latin-1/win-1252 charset) language market
>for Tamil Language.
>
>If you know of any other problems of TSCII, please post them in
>the mailing list immediately.
>
>
>Proposed Revision of TSCII
>
>To accelerate the process, Muthu Nedumaran, Manivannan, Kalyan,
>Sivaraj and Ravindran Paul met at KL right after the TI2001
>conference and reviewed possible options to take care of the
>above problems.
>
>Given the large number of user-base and significant amount of
>Tamil database generated during the past four years for TSCII
>(e.g. Project Madurai, aaraamthinai website, numerous mailing
>lists), a preferred option is to go for some minor revision
>(version 1.7), one that will take care of the "i" problem.
>
>One possibility here is to move "i" to the vacant slot #254.
>Of course, such a shifting of a single "uyir" will break the
>natural ordering (neTungkaNNu varisai) of uyirs in the scheme.
>In our view, a single exception case can be adequately handled
>in search, sorting routines (Tamil sorting in any case cannot
>be done using that of ASCII).
>
>Keeping "i" in the current slot (173) but as a DEPRECATED glyph
>will allow access to the entire database generated till date.
>(A deprecated glyph is one that will be present in all font
>faces corresponding to revised TSCII but whose usage in any
>applications or OS is forbidden. Its presence is solely for
>backward compatibility reasons. Unicode revision of characters
>is done in this manner- no characters are deleted during
>revision).
>
>Regarding bad word-break occurring right after "thu", it is
>our opinion that this problem can be handled in dedicated Tamil
>software and does not require reshuffling of the entire slot
>allocations.
>
>It is also proposed that, font-faces prepared according to
>the revised (version 1.7) scheme will carry "TSC" as a prefix,
>rather than as suffix currently in use. Thus fonts of TSCII
>1.7 scheme are to be named as TSCxxxxx where xxxxx is the name
>of the font-face. Placing TSC in the prefix (as in TAB fonts)
>allow fonts of a given encoding all to appear together in
>the font selection menu.
>
>Above suggestions are some starters to begin discussions.
>So please feel free to comment on these and alternatives.
>
>Muthu Nedumaran
>K. Kalyanasundaram
>M. Manivannan
>D. Sivaraj
>Ravindran K. Paul
>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
>
>To unsubscribe from this group, send an email to:
>tamilcomputing-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Kumar Mallikarjunan, Ph.D.
Assistant Professor
Biological Systems Engineering Department
312 Seitz Hall, Virginia Tech
Blacksburg, VA 24060
Ph: 540-231-7937  Fax: 540-231-3199
email: kumar@...

Dear Friends:

One of the important decisions of INFITT announced at TI2001
conference was recognition of TAB and TSCII as the two most
widely used 8-bit bilingual glyph encodings on the Net and
recommendation that these two encodings alone be used from now
on in all Tamil information interchange through the Net
(TAM recommended for cases where monolingual encoding usage
is deemed necessary).

It was also suggested during the meetings that, if there are
any problems being faced in the existing encodings, the people
with experience in those encodings may discuss those problems
and suggest backward compatible changes to those encodings.

It is time now for people involved in TSCII efforts to engage
in discussions as to whether TSCII in the present form,
version 1.6 (for details see the gif at
	 http://www.geocities.com/Athens/5180/charset16.gif )
is adequate for all our needs or should be revised.


TSCII mailing list and TSCII website

Discussions on TSCII revision will take place from now on in
the mailing list <tscii@yahoogroups.com>. This will be the
last posting on this topic copied to all Tamil mailing lists.

Archives of the list <tscii@yahoogroups.com> will be open for
all those interested to follow the discussions (currently
archive open only to members but this will be changed).
Those interested to participate in the TSCII revision
discussions should sign up by visiting yahoo site
   http://groups.yahoo.com/group/tscii/

We now have the domain name <www.tscii.org> registered and
this site will be used to provide all information related to
TSCII encoding.  Existing site <www.tamil.net/tscii> will
continue as a mirror site.


Problems of TSCII encoding

TSCII has been in use widely for nearly four years without
major problems in several modes of information interchange
such as emails, mailing lists, websites, pdf files and desktop
publishing in three major computer platforms (windows,
macintosh and unix).

One persistent problem noticed during the past two years is
handling of third uyir letter "i" (encoded slot # 173) in some
of the key Microsoft application softwares running under
Windows OS (e.g. Internet Explorer, Outlook Express and MS Word).
Even today Sun Star Office package of Win OS handles TSCII
cleanly. The above problem is due to over-riding of "i" at the
unprotected slot (#173) of soft-hyphen of win-1252/ANSI schemes.

One other documented problem noted is bad word-break that occurs
(right after the uyirmei letter "thu" when Tamil Texts are used
in justified format during DTP publishing in MS-Word and related
softwares. This is the outcome of using shrink-wrap softwares
created for English (Latin-1/win-1252 charset) language market
for Tamil Language.

If you know of any other problems of TSCII, please post them in
the mailing list immediately.


Proposed Revision of TSCII

To accelerate the process, Muthu Nedumaran, Manivannan, Kalyan,
Sivaraj and Ravindran Paul met at KL right after the TI2001
conference and reviewed possible options to take care of the
above problems.

Given the large number of user-base and significant amount of
Tamil database generated during the past four years for TSCII
(e.g. Project Madurai, aaraamthinai website, numerous mailing
lists), a preferred option is to go for some minor revision
(version 1.7), one that will take care of the "i" problem.

One possibility here is to move "i" to the vacant slot #254.
Of course, such a shifting of a single "uyir" will break the
natural ordering (neTungkaNNu varisai) of uyirs in the scheme.
In our view, a single exception case can be adequately handled
in search, sorting routines (Tamil sorting in any case cannot
be done using that of ASCII).

Keeping "i" in the current slot (173) but as a DEPRECATED glyph
will allow access to the entire database generated till date.
(A deprecated glyph is one that will be present in all font
faces corresponding to revised TSCII but whose usage in any
applications or OS is forbidden. Its presence is solely for
backward compatibility reasons. Unicode revision of characters
is done in this manner- no characters are deleted during
revision).

Regarding bad word-break occurring right after "thu", it is
our opinion that this problem can be handled in dedicated Tamil
software and does not require reshuffling of the entire slot
allocations.

It is also proposed that, font-faces prepared according to
the revised (version 1.7) scheme will carry "TSC" as a prefix,
rather than as suffix currently in use. Thus fonts of TSCII
1.7 scheme are to be named as TSCxxxxx where xxxxx is the name
of the font-face. Placing TSC in the prefix (as in TAB fonts)
allow fonts of a given encoding all to appear together in
the font selection menu.

Above suggestions are some starters to begin discussions.
So please feel free to comment on these and alternatives.

Muthu Nedumaran
K. Kalyanasundaram
M. Manivannan
D. Sivaraj
Ravindran K. Paul



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Dear Sir,

I would like to bring your attention to repetitive information such as
these in most 8859 discussions.

One of them from
http://www.cs.ruu.nl/wais/html/na-dir/internationalization/iso-8859-1-charset.ht\
ml
--- Quote --
ISO 8859-X character
sets use the characters 0xa0 through 0xff to represent national
characters, while the characters in the 0x20-0x7f range are those used
in the US-ASCII (ISO 646) character set.  Thus, ASCII text is a proper
subset of all ISO 8859-X character sets.

The characters 0x80 through 0x9f are earmarked as extended control
chracters, and are not used for encoding characters.  These characters
are not currently used to specify anything.  A practical reason for
this is interoperability with 7 bit devices (or when the 8th bit gets
stripped by faulty software).  Devices would then interpret the character
as some control character and put the device in an undefined state.
(When the 8th bit gets stripped from the characters at 0xa0 to 0xff, a
wrong character is represented, but this cannot change the state of a
terminal or other device.)
-- End Quote --

http://members.aol.com/_ht_a/drmcpal/html/zeichensatz.htm#iexentity
--- Quote --
They are in the region -Ÿ and are not supported by Netscape. For
the ™ entity however, Netscape will only understand ™,
-- End Quote --

Personal observation:
If swapping nku,nkU,nsu,nsU to safe areas is possible without affecting
"very much" the exisiting softwares, it might be useful.

Regards,
        Lak Sri



"K. Kalyanasundaram" <kalyan@...> on 07/07/2001 12:51:30 AM

Please respond to tscii@yahoogroups.com

To:   tscii@yahoogroups.com, muthu@..., mmanivannan@...
cc:
Subject:  Re: [tscii] Fw: RFC - Conversion of TamilKDE/TamilGnome from
       TSCII to  TAB.



Dear Mani:.
I do not fully understand the reasons behind
the claims of Nadarajah on TSCII.

> After much head scratching, we the TamilKDE and
> TamilGnome translation teams are considering
> switching the encoding of the translation files
  > from the TSCII to TAB. The main reason for this
> (from our perspective) is that TSCII is not in full
> compliance with the iso-8859-xx encoding standards
> and hence many applications (both new and old new ones)
> have diffculty in displaying/printing characters in
> the 'special' slots from 128 to 161.

As with WG4 discussions, Nadarajah is very vague
in his statements without citing specifics on the
problems if any. I wonder if Nadarajah and co
did go through TSCII discussions archive and
whether their worries are based on their own
findings.

If the worries are based on their own findings,
I would like to hear the details first. These
will certainly help proposed revisions ofTSCII.

It is my understanding that, only some of the
slots in rows 8 and 9 cause problems and not the
entire block of slots 128-159. ANSI encoding, for
one uses nearly half othe slots of rows 8 and9.

During the TSCII discussions we did discuss these
issues and placed Tamil glyphs in the safe slots
and filled Tamil numerals alone in the "risky"
slots. So, IMHO, if at all there are problems
they should arise only in the handling of the
Tamil numerals.

I also do not understand the arguments if any
as to why any language encoding has to follow
ISO 8859-x schemes. There are other officially
recognized encodings like those of Russian KOI8-R
and Vietnamase, MacRoman which use rows 8 and 9.

Kalyan

To unsubscribe from this group, send an email to:
tscii-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Dear Mani:.
I do not fully understand the reasons behind
the claims of Nadarajah on TSCII.

> After much head scratching, we the TamilKDE and
> TamilGnome translation teams are considering
> switching the encoding of the translation files
  > from the TSCII to TAB. The main reason for this
> (from our perspective) is that TSCII is not in full
> compliance with the iso-8859-xx encoding standards
> and hence many applications (both new and old new ones)
> have diffculty in displaying/printing characters in
> the 'special' slots from 128 to 161.

As with WG4 discussions, Nadarajah is very vague
in his statements without citing specifics on the
problems if any. I wonder if Nadarajah and co
did go through TSCII discussions archive and
whether their worries are based on their own
findings.

If the worries are based on their own findings,
I would like to hear the details first. These
will certainly help proposed revisions ofTSCII.

It is my understanding that, only some of the
slots in rows 8 and 9 cause problems and not the
entire block of slots 128-159. ANSI encoding, for
one uses nearly half othe slots of rows 8 and9.

During the TSCII discussions we did discuss these
issues and placed Tamil glyphs in the safe slots
and filled Tamil numerals alone in the "risky"
slots. So, IMHO, if at all there are problems
they should arise only in the handling of the
Tamil numerals.

I also do not understand the arguments if any
as to why any language encoding has to follow
ISO 8859-x schemes. There are other officially
recognized encodings like those of Russian KOI8-R
and Vietnamase, MacRoman which use rows 8 and 9.

Kalyan

----- Original Message -----
From: "Dinesh Nadarajah" <n_dinesh@...>
To: <tamilinix@yahoogroups.com>; <wg07infitt@yahoogroups.com>;
<wg01-infitt-experts@yahoogroups.com>; <INFITT_NorthAmerica@yahoogroups.com>
Sent: Friday, July 06, 2001 12:13 PM
Subject: [wg01-infitt-experts] RFC - Conversion of TamilKDE/TamilGnome from
TSCII to TAB.


> After much head scratching, we the TamilKDE and
> TamilGnome translation teams are considering
> switching the encoding of the translation files
> from the TSCII to TAB. The main reason for this
> (from our perspective) is that TSCII is not in  full
> compliance with theiso-8859-xx encoding standards and hence many
> applications (both new and old new ones)
> have diffculty in displaying/printing characters in
> the 'special' slots from 128 to 161.
>
> We have not heard anything of the TAB 2.0 standard
> that is supposed to
> merge the two and provide a single guidance point,
> but then we have no
> clue as to the form of TAB 2.0. Is it going to be
> TSCII like or TAB
> like? Have they taken into account the 128-161 range
> issue. Is the new
> encoding going to be standadized as a iso-8859-xx
> standard for Tamil
> (that would be very welcome). What effect will
> TAB 2.0 have on the Tamil Unicode block?
>
> We have not finalized our this dicision. We would
> like to hear more about this from the  greater
> Tamil/Linux/Unix  community and if possible  shed
> some light on
> these issues. We would also appreciate some guidance
> from those of you  who are involved in the
> standards work.
>
> Thanks & Regards,
>
> TamilKDE and TamilGnome

Mani:

Thanks. I was out of town for the past week. I am back in the office. I
will send the TSCII 2.0 Proposal to the INFITT WG04 sometime today.

Kumar.

At 6/25/2001 04:07 AM +0000, you wrote:
>Kumar,
>
>You had raised the TSCII 2.0 proposal in the INFITT WG4 discussion
>and there were interests from other members about that proposal.
>
>It is my recollection that we had agreed to merge the TSCII and TAB
>specifications into a TAB 2.0 by TI 2001.  If it will take longer
>than that to integrate the two competing specs, then it will be a
>great disservice to the loyal TSCII users.
>
>Can you post the TSCII 2.0 proposal to this list so that TSCII
>developers and users can comment on the proposal.  In case TAB 2.0
>does not come about by TI 2001, TSCII developers can go ahead and
>implement TSCII 2.0.
>
>What do you think?
>
>Regards,
>
>Mani M. Manivannan
>
>
>To unsubscribe from this group, send an email to:
>tscii-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Kumar Mallikarjunan, Ph.D.
Assistant Professor
Biological Systems Engineering Department
312 Seitz Hall, Virginia Tech
Blacksburg, VA 24060
Ph: 540-231-7937  Fax: 540-231-3199
email: kumar@...

Kumar,

You had raised the TSCII 2.0 proposal in the INFITT WG4 discussion
and there were interests from other members about that proposal.

It is my recollection that we had agreed to merge the TSCII and TAB
specifications into a TAB 2.0 by TI 2001.  If it will take longer
than that to integrate the two competing specs, then it will be a
great disservice to the loyal TSCII users.

Can you post the TSCII 2.0 proposal to this list so that TSCII
developers and users can comment on the proposal.  In case TAB 2.0
does not come about by TI 2001, TSCII developers can go ahead and
implement TSCII 2.0.

What do you think?

Regards,

Mani M. Manivannan

VR,

Just finished a good long Yahoo! chat with Kalyan ;-)

The problem with some, esp. grantha, characters in Aaraamthinai/Netscape is now
clear. If you check out the source, these characters are represented with their
"&..." quivalents - which is what's causing the problem.

Here's Kalyan's summary of the discussion :

"I am talking here only about granthas. As I said, if the html page is properly
done with native 8 bit characters, Netscape renders them properly on both Mac
and Win. On windows, possibly in earlier Netscape versions, they interpreted
7-bit equiv string (&xxxx  but not now. As per HTML specs, any character that is
defined by ambersand sequence (&xxxxx  is automatically interpreted as Latin-1
EVEN IF THE META header invokes a different character set."

Could you check on the editor your folks are using?  Perhaps setting the
encoding to user-defined there may help.

~ MUTHU

Kalyan and all,

Here are my comments.

Let's start this as "iProject" (hope this word is not taken) and follow the same
process as we did when we formulated TSCII - i.e lets state the  problem and the
various options available for a resolution - Kalyan has (again) provided a
brilliant summary if we decide to move the characters around.

Issues that I think we should (seriously) consider are (IMHO) :

1. The problem only exists in IE and any application that uses the IE
HTML-component and these too only on the Win32 platforms.

    We took two paths to see light on this.  One was Venkata Rangan's
communication with the IE group within MS. They have stated that the behaviour
of the soft-hyphen (in our case the 'i') is not going to change in IE. Their
recommendation is for us to use Unicode. So this path is closed. I'll forward
this to the list later.

    The other path is with the OpenType group that I'm persuing.  IE5.5 (and
future versions) bundle a scripting engine called Uniscribe that renders complex
scripts correctly through many mechanisms - one such mechanism is GSUB tables. 
If we could figure out a way to substitute "space"+"i" with a glyph that
includes space - this can be a great (though interim) solution as we can
continue work with TSCII 1.6. There are also other combinations - like newline
and "i", tab and "i" etc... but the list is only limited. The EOT technology can
be used to render TSCII pages with dynamic fonts.  Venkat and I are working on
this for Aaraamthinai.Com.  If this works - this'll take care of the "i" problem
in IE/Win32 - which is our only problem now.  Note that the GSUB will *not*
affect the internal representation of the text - so work goes on as normal. Note
that Win2K, WinMe and future MS platforms are defaulting to OpenType - so we
will be building OpenType (instead of True Type) fonts for Windows.  I'm also
working to implement GSUBs to render ikara and iikaara varisai in TSCII for
aesthetics - something we talked about at length a few years ago.

2. We need to revise TSCII ultimately - to move "i" out of the soft-hyphen space
- I'm still hopeful (even more now) that we can realise this as a single
standard with TAB 2.0 (ok...scold me !). Until then, I thought we can work on
alternatives (in parallel to what Kalyan has proposed) so the the migration need
not happen immediately.

3. If TAB 2.0 does *not* meet our design goals (requirements), we will have to
fall back to TSCII 2.0 which will be the "i"-corrected version of TSCII.

These are just some thoughts I think we should keep in mind as we do not want to
work with too many / too frequent migrations.

anbudan,

~ MUTHU

---------- Original Message ----------------------------------
From: "K. Kalyanasundaram" <kalyan@...>
Reply-To: tscii@egroups.com
Date: Fri, 29 Sep 2000 17:22:40 +0200

>Dear Friends:
>
>I posted the following comments two days ago to Muthu and others
>but haven't seen any response on it. Hence this repost.
>
>>
>>Dear Muthu and friends:
>>
>>At 13:50 -0700 24/9/00, Muthu Nedumaran wrote:
>>>Friends,
>>>
>>>Looks like we may *have* to change the location 'i' in TSCII 1.6 after
>>>all. It occupies soft-hyphen in the "Windows" character set and the
>>>recommendation below (from w3) suggests that this character is normally
>>>invisible - so MS has a case.
>>>
>>>http://www.w3.org/MarkUp/HTMLPlus/htmlplus_13.html
>>>
>>>This character is also refered to as "minus" and I tried replacing the
>>>'i's with &minus; I used a modified TSCII font that has a duplicate 'i' -
>>>one named as soft-hyphen and the other named as 'minus'.  Tthe editor I
>>>used (outlook express) replaced my &minus; with ? - it works fine
>>>for IE but not for Netscape.
>>>
>>>I'm still struggling :-(
>>
>>It has been a couple of years since we discussed and finalised
>>TSCII in the present version 1.6. Somehow I was thinking that only
>>the last slot #255 was left vacant. Recently when I looked at the
>>gif file at <http://www.tamil.net/tscii/charset16.gif> I notice that
>>we do have the last TWO slots left vacant (#254 and #255). The
>>second slot became vacant after we decided to drop the "registered"
>>sign from the basic repertoire of version 1.5.
>>
>>Following are some of the options we can pursue:
>>
>>i) reassign the glyphs in the present sequence, after leaving the
>>troublesome slot of 173 where "i" resides now. This would mean
>>that all of the existing TSCII based texts will not be readable
>>using a font corresponding to version 1.7 and one needs to use a
>>text convertor to go between texts of version 1.6 and 1.6
>>
>>ii) simply place the uyir letter "i" at slot 254 and delete it from
>>the present location of 173, conforming still to the basic principle
>>of unique representation of the glyphs in the repertoire. Advantage
>>of this option is that TSCII texts of version 1.6 will be still
>>readable using fonts of version 1.7 but for this single character
>> i.
>>
>>Unpleasant aspect of this option (ii) is that search, sort engines
>>have to take into account this non-sequential appearance of the
>>basic uyirs in the scheme, with i orphaned and placed at the end.
>>But, for the end-users this is of no serious consequence.
>>
>>Duplication the glyph "i" at 254 while leaving it at present
>>slot of 173 is not possible, since all keyboard editors have to
>>configured for i that is at one slot position or the other. Also,
>>such duplications violate basic design principles of having
>>unique, unambiguous representation of characters in the encoded
>>scheme.
>>
>>Given the necessity to utilise a convertor to read all
>>data generated using version 1.6, it appears that option (ii)
>>appears better.
>>
>>I would like to hear pros and cons for these two options and
>>others you can think of.
>>
>>Kalyan
>>
>>
>
>
>
>
>To unsubscribe from this group, send an email to:
>tscii-unsubscribe@egroups.com
>
>
>
>

Kalyan:

I added some discussion on this and felt that we could go with option 2.
Using the slot #254 for "i". Though it is not an ideal solution, it may
be easier to adopt from the old encoding 1.6. However, I commented that
the best solution should be to skip #173 and reallocate all the slots.
This will be a chaos as 1.6 and 1.7 would not be compatible at all.

Mani mentioned about TANSCII.

Regards,

Kumar.

At 9/29/00 05:22 PM +0200, you wrote:
>Dear Friends:
>
>I posted the following comments two days ago to Muthu and others
>but haven't seen any response on it. Hence this repost.
>
> >
> >Dear Muthu and friends:
> >
> >At 13:50 -0700 24/9/00, Muthu Nedumaran wrote:
> >>Friends,
> >>
> >>Looks like we may *have* to change the location 'i' in TSCII 1.6 after
> >>all. It occupies soft-hyphen in the "Windows" character set and the
> >>recommendation below (from w3) suggests that this character is normally
> >>invisible - so MS has a case.
> >>
> >>http://www.w3.org/MarkUp/HTMLPlus/htmlplus_13.html
> >>
> >>This character is also refered to as "minus" and I tried replacing the
> >>'i's with − I used a modified TSCII font that has a duplicate 'i' -
> >>one named as soft-hyphen and the other named as 'minus'.  Tthe editor I
> >>used (outlook express) replaced my − with − - it works fine
> >>for IE but not for Netscape.
> >>
> >>I'm still struggling :-(
> >
> >It has been a couple of years since we discussed and finalised
> >TSCII in the present version 1.6. Somehow I was thinking that only
> >the last slot #255 was left vacant. Recently when I looked at the
> >gif file at <http://www.tamil.net/tscii/charset16.gif> I notice that
> >we do have the last TWO slots left vacant (#254 and #255). The
> >second slot became vacant after we decided to drop the "registered"
> >sign from the basic repertoire of version 1.5.
> >
> >Following are some of the options we can pursue:
> >
> >i) reassign the glyphs in the present sequence, after leaving the
> >troublesome slot of 173 where "i" resides now. This would mean
> >that all of the existing TSCII based texts will not be readable
> >using a font corresponding to version 1.7 and one needs to use a
> >text convertor to go between texts of version 1.6 and 1.6
> >
> >ii) simply place the uyir letter "i" at slot 254 and delete it from
> >the present location of 173, conforming still to the basic principle
> >of unique representation of the glyphs in the repertoire. Advantage
> >of this option is that TSCII texts of version 1.6 will be still
> >readable using fonts of version 1.7 but for this single character
> > i.
> >
> >Unpleasant aspect of this option (ii) is that search, sort engines
> >have to take into account this non-sequential appearance of the
> >basic uyirs in the scheme, with i orphaned and placed at the end.
> >But, for the end-users this is of no serious consequence.
> >
> >Duplication the glyph "i" at 254 while leaving it at present
> >slot of 173 is not possible, since all keyboard editors have to
> >configured for i that is at one slot position or the other. Also,
> >such duplications violate basic design principles of having
> >unique, unambiguous representation of characters in the encoded
> >scheme.
> >
> >Given the necessity to utilise a convertor to read all
> >data generated using version 1.6, it appears that option (ii)
> >appears better.
> >
> >I would like to hear pros and cons for these two options and
> >others you can think of.
> >
> >Kalyan
> >
> >
>
>
>
>
>To unsubscribe from this group, send an email to:
>tscii-unsubscribe@egroups.com

Kumar Mallikarjunan, Ph.D.
Assistant Professor
Biological Systems Engineering Department
312 Seitz Hall, Virginia Tech
Blacksburg, VA 24060
Ph: 540-231-7937  Fax: 540-231-3199
email: kumar@...

Dear Friends:

I posted the following comments two days ago to Muthu and others
but haven't seen any response on it. Hence this repost.

>
>Dear Muthu and friends:
>
>At 13:50 -0700 24/9/00, Muthu Nedumaran wrote:
>>Friends,
>>
>>Looks like we may *have* to change the location 'i' in TSCII 1.6 after
>>all. It occupies soft-hyphen in the "Windows" character set and the
>>recommendation below (from w3) suggests that this character is normally
>>invisible - so MS has a case.
>>
>>http://www.w3.org/MarkUp/HTMLPlus/htmlplus_13.html
>>
>>This character is also refered to as "minus" and I tried replacing the
>>'i's with − I used a modified TSCII font that has a duplicate 'i' -
>>one named as soft-hyphen and the other named as 'minus'.  Tthe editor I
>>used (outlook express) replaced my − with − - it works fine
>>for IE but not for Netscape.
>>
>>I'm still struggling :-(
>
>It has been a couple of years since we discussed and finalised
>TSCII in the present version 1.6. Somehow I was thinking that only
>the last slot #255 was left vacant. Recently when I looked at the
>gif file at <http://www.tamil.net/tscii/charset16.gif> I notice that
>we do have the last TWO slots left vacant (#254 and #255). The
>second slot became vacant after we decided to drop the "registered"
>sign from the basic repertoire of version 1.5.
>
>Following are some of the options we can pursue:
>
>i) reassign the glyphs in the present sequence, after leaving the
>troublesome slot of 173 where "i" resides now. This would mean
>that all of the existing TSCII based texts will not be readable
>using a font corresponding to version 1.7 and one needs to use a
>text convertor to go between texts of version 1.6 and 1.6
>
>ii) simply place the uyir letter "i" at slot 254 and delete it from
>the present location of 173, conforming still to the basic principle
>of unique representation of the glyphs in the repertoire. Advantage
>of this option is that TSCII texts of version 1.6 will be still
>readable using fonts of version 1.7 but for this single character
> i.
>
>Unpleasant aspect of this option (ii) is that search, sort engines
>have to take into account this non-sequential appearance of the
>basic uyirs in the scheme, with i orphaned and placed at the end.
>But, for the end-users this is of no serious consequence.
>
>Duplication the glyph "i" at 254 while leaving it at present
>slot of 173 is not possible, since all keyboard editors have to
>configured for i that is at one slot position or the other. Also,
>such duplications violate basic design principles of having
>unique, unambiguous representation of characters in the encoded
>scheme.
>
>Given the necessity to utilise a convertor to read all
>data generated using version 1.6, it appears that option (ii)
>appears better.
>
>I would like to hear pros and cons for these two options and
>others you can think of.
>
>Kalyan
>
>

TSCII group members:

I think we should try to resume the discussion on the 'i' issue head on.

It seems like the location for 'i' will not come free in the future for our
use.
It would be wise to drop that. Then what is the course of action. Mani
mentioned
about looking into TANSCII proposal. TANSCII was more or less close to TSCII.
Can Kalyan and Mani provide the similarities and differences between those.

Regards,

Kumar.




Kumar Mallikarjunan, Ph.D.
Assistant Professor
Biological Systems Engineering Department
312 Seitz Hall, Virginia Tech
Blacksburg, VA 24060
Ph: 540-231-7937  Fax: 540-231-3199
email: kumar@...

Dear Mani:
Thanks for subscribing me to this TSCII mailing list. It is
high time we open up one such dedicated list and discuss the
future of TSCII.

>
>Here's a description of the group:
>------------------------------------------------------------------------
>
>Tamil Standard Code for Information Interchange (TSCII) discussion list
>
>------------------------------------------------------------------------
>

Just one small note on the header. Many have their adrelin pressures
go up when they see the words "Standard" in TSCII. I think earlier
with Muthu, we agreed for a more softer yet precise expansion of
the acronym TSCII as
   TAMIL SCRIPT CODE FOR INFORMATION INTERCHANGE

Can we use this from now on, till we have an Internet Draft and
RFC launched?

Kalyan