[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PuTTY] : status
- To: Simon Tatham <anakin at pobox dot com>
- Subject: Re: [PuTTY] : status
- From: Kamal Dalal <kamal_dalal at yahoo dot com>
- Date: Tue, 18 Jun 2002 21:14:47 -0700 (PDT)
- Cc: putty at projects dot tartarus dot org, developer at arabeyes dot org
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
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
> > 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.
> 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