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

[<jk...@Fr...>]

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