[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PuTTY] : status


Thanks for your feedback, it is much appreciated. See comments below.

--- Simon Tatham <anakin at pobox dot com> wrote:

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

Agreed. I am abandoning the idea to rely on windows.

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

Makes sense. Still, when a selection is copied to the clipboard, the
glyphs (in terminal.c) should be converted to their original input. I can
also see a logical array and a visual array with clear and deterministic
transformation functions from one to the other.
> 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.

Needless to say, I am looking forward to graduate from the other school ;)
. Guess what my graduation project is ?

> 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

Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup