Re: [Indic-computing-devel] Fw: IndLinux Effort ...

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

> From: "J. Patricia Annie JebaMalar" <pa...@la...>
> Subject: IndLinux Effort ...

Thank you Karunakar, for forwarding this announcement.

First question: how many teams are there sharing the name "indlinux"?
I know of two now: 

  (1) indlinux at IIT-Madras and 
  (2) indlinux at SourceForge.Net.  

Is the work that they are doing related?

> http://www.tenet.res.in/Donlab/Indlinux/

The web page talks about a ``Newly Modified XLIB'' ... so I went to
have a look at the code.  Comments follow.

I don't mean to be harsh here; let me first say I appreciate the fact
that someone has done work in this area and has made their work public
for review.  Thank you!

However, as this implementation stands, this work is unlikely to end
up in any standard distribution.  If the IIT-M folks had had access to
better X expertise, my guess is that the end-result would have been
more acceptable.

o The ``Display'' structure has a number of new fields
  ``indian_font'', which is presumably a font name, and many `_flag'
  variables set when certain keys are pressed (left arrow, backspace
  etc) and many others.

o There seems to be some basic confusion between character encodings
  (eg:- ISCII) and font encodings (font specific) ---
  XDrawImageString() and XDrawString() have been hacked as follows:
  
  - if the glyph index being passed in is greater than 0xA0 and less
    than 0xFF, the routine tries to use the ``indian font'', if not it
    uses the ``normal font''.  A number of XSetFont() calls can thus
    result ``behind the scenes'' when XDrawString() is invoked.
    
    Recall that the ``indian font'' is fixed per DISPLAY, meaning an
    application can't have different ``indian fonts'' loaded
    simultaneously ...

  - Keypresses for some of the arrow keys set the `*_flag' variables
    in their modified display structure.  These flags can change the
    behaviour of XDraw{Image,}String() -- i.e. if the left/right arrow
    key had been pressed sometime before an XDraw{Image,}String
    occurred, then the behaviour of this function will be different.
    
    Changing behaviour per display because a left, right or up arrow
    is pressed seems strange.  Input focus can move to any window
    between two keystrokes and XDraw{Image,}String() can be invoked
    for multiple windows in the application in any order. 

    These functions are not the place to keep record of application
    keyboard state.

  - Lots of hacks and hardcoded behaviour: looking up of environment
    variables ("APP_TYPE") from inside these functions to determine
    behavioural changes like special case handling of BackSpace,
    Left-Arrow etc (with variants of this behaviour being hardcoded
    for applications like "KDE konsole", etc).

o Hacks to XDrawLine(!) to modify behaviour if the line for the cursor
  being drawn and if so if its in the middle of a displayed ``indian
  language string''.  Here also environment variable "APP_TYPE" plays
  its magic role.  I see calls to XGetWindowAttributes(), XClearArea()
  in the code ... the flags `left_flag', `right_flag' etc determine if
  XClearArea() will clear areas left or right of the nominal cursor
  insertion point!

  XDrawLine is supposed to draw a LINE, not do all this stuff.

o Another change to XNextEvent(), interacting with the hacks done in
  in XDrawLine().

o Changes to XkbLookupKey* to deal with the various
  {up,down,left,right}_flag variables introduced.

o Modularity of the library code broken (functions now "know" about
  each others' behaviours) ; namespace pollution (new function names
  in the library that do not confirm to the X library conventions and
  that can collide with existing application names), unneeded includes
  of headers files etc.  Some new files.

Whats wrong?

1. X applications are event-driven in nature, yet this code assumes
   that certain functions (XDraw{Image,}String()) WILL get called
   immediately after some keyboard event happens and that these calls
   to XDraw{Image,}String() are ``related'' to the keypress.

   This is broken.

2. The glyph indices passed to XDrawString() and XDrawImageString()
   are just that -- glyph indices specific to one font.  They are not
   necessarily 'character codes'.  You can have `8 bit Latin fonts'
   with standard characters 'a'--'z' mapped into any of the glyph
   indices 0..255.  The APPLICATION is responsible for sending the
   proper glyph indices to the X server.

   These changes ASSUME that glyph indices 0..159 correspond to one
   character encoding and 160..255 correspond to another.  This is
   wrong.
   
3. Lots of intrusive changes to the standard X library.  The changes
   are trying to do things in X library which just do not belong there
   (like keeping track of [application specific] keystrokes and
   modifying the behaviour of other library calls).

4. Hardcoded hacks in the X library that work-around problems that
   come about because of (1),(2) and (3) above.

:Summary:

Some of the basic premises behind the design of this code have to be
re-examined before it can effectively support indian languages and
before this code can become part of a mainstream distribution.

Regards,
Koshy
<jk...@fr...>