Re: [PuTTY] : status

[Nadim Shaikli <shaikli at yahoo dot com>]

On Tue, 18 Jun 2002 10:13:19 +0100,
  "Simon Tatham" <anakin pobox com> wrote:
> 
> Kamal Dalal <kamal_dalal yahoo 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.

Simply put, I think what Simon is asking for is for Putty to be
completely self-reliant in regards to this issue.  In other words,
Putty should handle its own Bidi and its own Shaping and not rely
on Windows and uniscript -- that shouldn't too much problem given
the ability to "disable" microsoft's interaction.  This really
simplifies things for Kamal (but I don't want to speak for him :-)
given the ability to tap into fribidi.

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

I'm afraid most Arab (or any other Bidi Language) speaker would disagree
with a passion with that "school of thought".  Simply put, this boils
down to the following (and arabeyes has seen this first hand),

 a. Have a terminal emulator that does Bidi and shaping and be able to
    successful run __any__ UTF-8 supporting application without modifying
    anything.
-or-
 b. Leave the terminal emulator as is (xterm's stance) and modify _all_
    applications out there to do Bidi/Shaping.

Let's see what mlterm brought to the table -- with mlterm, I can now
save files with Arabic names, use vim, use less, use cat, use mutt, etc,
etc.  Without touching any of those applications -- I stumble on new
applications on a daily basis (ie. mined).  If an application supports
UTF-8, then I'm 99.9% guaranteed that it will work without issue.  It
is, then, rather self-evident that the least amount of work and the most
bang for your buck is the terminal emulator supporting Bidi/Shaping.

So why does this "school of thought" think so -- after all most of those
guys are very bright, accomplished people.  Simple really -- its not
something they use or need themselves and thus resort to simply forgoing
looking into the issue and opt to throw it overboard and make it someone
else's problem (rightfully or not) -- and I don't mean any disrespect
to anyone.

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

I'd vote for a enable/disable option in which Bidi/Shaping is either
on/off per a user setting.  Bidi/Shaping should really be considered
an option; it should __not__, thus, interfere with Putty's current
functionality (ie. it will not break anything and ought not get in
the way).  Mlterm is a great example of how all of this could be
packaged-up (options and all)...

My $0.02's worth.

Regards,

 - Nadim


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com