Re: Unanswered Questions!

["Muthu Nedumaran (Ezil)" <mnedumar@sg.oracle.com>]

Nagu,

My inputs :-)

At 08:18 PM 9/13/97 -0400, Nagarajan Chinnasamy wrote:
>NanbarkalE,
>
>I thought I would just list the things that are still not answered
>in this list:
>
>Issues:
>
>  1. 8-bit Vs 7-bit.
>
>     8-bit **input** needs a background process running. How much
>     is it practical to input 8-bit codes on POS, Character Terminals,
>     DOS/PCs etc.???
>
>     ANS:(I am just trying :-))
>
>     I just vaguely remember that its something to do with keyboard
>     escape code mapping and/or loading the graphical character set
>     (if the terminal allows graphical mode).
>
>           OR
>
>     write Tamil Input Library using Curses which will on reception
>     of equivalent keyboard escape sequences map them to the Tamil
>     character. But this method does not work with the existing
>programs.
>
>     One advantage of Tamil on Character Terminals is: it will work out
>     very very cheap for Business purposes.

a. You're right about "existing apps" for POS systems - they can't 
   automatically have Tamil without software modification.

b. I see the input method for POS Tamil apps to be an integral part of
   the app itself.  Though we can work on standard libraries that can
   be linked, the input handling must be performed by the app.  This
   will require the app. to interpret every keystroke.

c. An alternative will be to write a TERMCAP (at least for UNIX systems)
   for the type of terminal that'll be used.  This is fairly easy but
   *limits* the use to only *certain* type of terminals.  The tradeoff
   is worth it from a cost perspective.  WYSE60 (and newer series) TTYs
   allow us to do this (I've done that before ;-) ).

d. IMHO, most POS applications do not rely too much on the keyboard in
   *production mode*. Input is usually through menus (numbers to select
   them), bar-codes and such.  However having Tamil capability in them 
   gives us the *option* of displaying messages and details in Tamil as
   well.  Data entry is usally a one-time effort, for which Windows/Macs
   with graphical inputs can be used (if reqd).

e. If we do (4), we *do not* need a Tamil input method on terminals.
   Just a bit-mapped font will do the *trick*.

>  2. Inclusion of Old-Style Tamil Letters/Transliteration Schemes.
>
>     ANS:I think its almost technically answered. Just waiting for
>Kalyan's
>     "Yes".

He has already said Yes I guess :-)

>  3. Three standards: 7-bit, 8-bit, Unicode/ISCII based.
>
>     ANS: Is it seriously asked?? :-). May be if we are not able to do
>     8-bit input in POS, Character Terminals, etc., we can really think
>     about 7-bit standard. 8-bit standard is a temporary (atleast till
>     Unicode/ISCII become practical standards).

We *can* input 8-bits in POS terminals.  Mapping tamil on 7-bit is 
especially problematic for POS systems as the do not have anything
close the <FONT FACE ... > ;-)

>  4. Encoding "Ksha" as a character.
>
>     ANS: If it is there in the Table, and as far as we dont need those
>          positions, they can be there. Technically we are not losing
>          anything.
>
>          But personally what I feel is(And I hope its generally logical
>          too!), A language need not have a redundant/unnecessary
>          **character** in its character list. By having it in our
>Table,
>          we are encouraging the people to use it as a separate
>character.
>          But actually it is just a style of writing combined letters.
>          We are not losing any **sound** by leaving it.

Sorry Nagu, I do not think I'm qualified to do an analysis on ksha. It's
OK for me both ways.  Having it there appears easier to me and I do not
see any ambiguity ;-)
   
>Things To Do List:

I'm skipping this...for now.

anbudan,

~ MUTHU