Re: [PuTTY] : status

[Simon Tatham <anakin at pobox dot com>]

Kamal Dalal <kamal_dalal at yahoo dot com> wrote:

> The right to left display was accomplished by simlpy reversing the input
> data before displaying. The letter shaping is courtesy of Windows.
[...]
> Comments any one ?

I think allowing Windows to do the letter shaping is doomed to
failure. As you've already noticed, the character under the cursor
is displayed separately and so it will be the wrong shape; more
generally, if you cover and then uncover parts of the PuTTY window
then only the erased text will be redrawn, and the same problem will
happen.

I think that I'd be unwilling to accept patches to PuTTY unless they
follow this one absolute principle:

  The terminal data structures in terminal.c _MUST_ reflect what is
  genuinely displayed in the window.

Therefore, if PuTTY is to do Arabic letter shaping, it _must_ do it
in such a way that the terminal data structures in terminal.c
reflect the post-shaping text rather than the pre-shaping text. So
the problem is now divided into two:

 (1) First find a way to make Windows display the exact characters
     it's given, instead of trying to second-guess, change
     direction, and do shaping. (We need this to be done anyway.)

 (2) Then make PuTTY itself do the bidi and shaping in terminal.c,
     between receiving text from the back end and storing it into
     the terminal data structures. So the text passed to window.c
     for display will already have had bidi and shaping done on it.

I've been investigating the whole bidi issue since you last mailed
us, and I've found that there's a sizable school of thought (notably
including xterm and luit) which believes that bidi and Arabic letter
shaping simply shouldn't be the job of a terminal emulator at all -
it should be the job of the application running on top of the
terminal emulator. Accordingly, xterm displays all text left to
right exactly as given, and if an application wants Arabic text
displayed RTL and shaped then it must arrange that itself.

The advantages of this position are:

 - It's simple. Terminal emulators are horribly complex _already_,
   and introducing yet more layers of complexity is almost certain
   to cause all sorts of nasty corner cases when bidi and shaping
   start to interact with other terminal features. Keeping terminal
   semantics simple keeps them testable and predictable.

 - Any screen-based application (such as an editor) needs to know
   exactly which characters are displayed in which character cells,
   so it can usefully move the cursor to the right place. Therefore,
   even if the terminal does bidi and shaping, the application must
   still compute all the bidi and shaping details _itself_, so that
   it can know where the terminal has put the text it sent. And
   furthermore, it must do it in _exactly_ the same way as the
   terminal did it - no minor variations in the algorithm can be
   allowed. It's silly to have both programs do the same calculation
   and risk them getting out of sync, when it would be easier to
   have just one program do it. And since the application must do it
   anyway, it should therefore be the only program doing it.

 - Most importantly for PuTTY: _it's what xterm does_. As long as
   PuTTY advertises itself to servers as terminal type `xterm', it
   _must_ continue to behave as much like xterm as possible, at
   least by default; and that means that any bidi and shaping
   support will be turned off by default, and characters will be
   displayed in simple left-to-right order and not shaped.

> 2. Terminal command . Need to find that in the bidi terminal spec posted
> earlier on this list.

Ah. Yes, this sounds like a plausible solution to the above; that
would mean that an editor or other screen-oriented application could
switch into a predictable left-to-right mode for all the above
reasons, but in a normal terminal session with no single controlling
application, text would be displayed in the right order.

If there's a defined control sequence to toggle bidi and shaping
mode, then probably the best solution is for PuTTY to support this
sequence _and_ to have a GUI configuration option to select its
initial state.

I should go and read the terminal spec you mentioned, really.

Cheers,
Simon
-- 
Simon Tatham         "Every person has a thinking part that wonders what
<anakin at pobox dot com>    the part that isn't thinking isn't thinking about."