Re: [Indic-computing-standards] [KB-IM] (1) what would you prefer - keyboard layouts

[Srinatha S. <sa...@ea...>]

Dear sirs,

Kannada Ganaka Parishat is happy to present a User-friendly Common Keyboard overlay

for Bengali, Gujarathi, Gurumukhi, Hindi, Kannada, Malayalam, Oriya, and Telugu
scripts.

Encouraged by the acceptance of such a standard for Kannada by the Government of
Karnataka, the whole hearted welcome by the users of Kannada in computers and the
success in using this standard for Kannada, Ganaka Parishat started thinking of
similar standards for the other Indian languages as well. This is because of the
identical structure of all our Indian languages. The idea was circulated among the
friends of other languages, who instantly evinced keen interest after ascertaining
the user friendliness of the suggested keyboard overlay. From then on, with the
untiring efforts of such brethren of the above-mentioned Indian languages, detailed

structures of user-friendly keyboard overlay have been worked out and the
corresponding documents have been prepared. The need, advantages and all other
related aspects regarding these standards have been elaborated in these documents.
It is important to note that all the language-specific issues have been addressed
in this exercise.

Kannada Ganaka Parishat and all other enthusiastic Indian language experts working
in this regard, expect that a national consensus be arrived at for a new Keyboard
overlay, which uses only the 26 keys (earmarked for English) on the computer
keyboard for Indian language character representation also, with the combination of

normal and shift keys only. We hope that this effort will be given due
consideration and the suggestions are implemented.

The author would like to record the services rendered by many members of Kannada
Ganaka Parishat, but for their intellectual contributions, the project would not
have succeeded. Special mention is needed about the contributions of Sri S K Anand,

Managing Director, Cyberscape Multimedia Ltd. and Sri Ashwin Sheshadri, Software
Engineer, Samyog Software, Bangalore. Sri Ashwin Sheshadri has joined us recently
in this exercise. With his amazing achievement of mastering fifty language scripts,

Sri Sheshadri has contributed to a large extent in this effort by addressing many
language-specific issues, suggesting the solutions and enumerating all the language

alphabets in the texts and charts.

Kannada Ganaka Parishat also acknowledges the support extended by the Government of

Karnataka agencies like Kannada Development Authority, Department of Kannada and
Culture, Department of Information Technology, Directorate of Information and
Technology, many individuals and some private organizations in this endeavor.
I have attached a semi-detailed document for Hindi. We have such documents for
other languages also. They also discuss language specific issues and try to give
solutions for such issues. If the line of thnking is acceptable to all, we can
circulate same, in instalments (in .gif format).

We are eager to get the reactions from all those who are interested in this
endeavour.

 C V SRINATHA SASTRY

General Secretary, Kannada Ganaka Parishat, Bangalore 560 019



Joseph Koshy wrote:

> gk> (a) A keyboard with <insert ur language> printed on it (lets say
> gk> (b) Keyboard like the ones available in market today (only roman) +
> gk> (c) Roman keyboard, using a phonetic or transliteration schemes for
>
> gk> Note: Its assumed that language support is already there using a
> gk> character based model . So output from keymap/keyb driver has to be
> gk> character codes. Also 'Keyboard' means the physical keyboard (XT/AT
> gk> model with 84/101/104 keys).
>
> A small correction: keyboards do not send over character codes under
> X.  The X server ALWAYS sends over (hardware specific) keycodes to the
> client.  This gets translated to KEYSYMS in the client using a
> per-display keyboard mapping table.
>
> Note: keysyms != character codes.  There can be keysyms for which no
> code point has been defined in Unicode/ISCII/<insert character set
> name>.
>
> The major objection I can see with the keymap and transliteration
> solutions floating around today is the following: in these schemes,
> the burden of providing the editing experience for the user falls on
> the application.  Rendering indic text (and providing feedback to the
> user while editing is taking place) is a complex task.  In a
> keymap/keysym based indic input method every application needs to be
> aware of how to carry out this task.
>
> Problems:
>
>   (a) code duplication
>   (b) the problem of subtle differences between implementations,
>       (or versions of the same application) causing subtle changes
>       in the user interface
>   (c) fragile (a US keyboard layout based keymap solution will break
>       on non-US keyboards)
>   (d) different indic languages have different input editing needs;
>       one size does not fit all
>   (e) misses an important point in the architecture of the X
>       Window System, namely the provision for input methods.
>
> That said, keymap based solutions are around today, but I haven't come
> across a indic input method for X.
>
> Regards,
> Koshy
> <jk...@fr...>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Indic-computing-standards mailing list  http://indic-computing.sourceforge.net/
> Ind...@li...
> https://lists.sourceforge.net/lists/listinfo/indic-computing-standards