Re: mlterm with BiDi support
> Hello Shaul,
> At Wed, 28 Nov 2001 01:33:51 +0200,
> Shaul Karl wrote:
> > I hope that mlterm also takes into considerations the RTL (Right To
> > Left) languages. As far as I know these are Hebrew and Arabic.
> > Actually, BiDi (Bi Directional) might be more suitable then RTL in this
> > context since users of these languages do expect to be able to combine
> > the other direction too. And by that I mean have Hebrew/Arabic text
> > combined with other languages text.
> mlterm version 2.1.0 with BiDi support using FriBidi will be released
> soon. However, some people insist that terminal emulators are not
> responsible for BiDi and application softwares are responsible (and
> thus terminal emulators should _not_ support BiDi).
I believe a terminal emulator is the natural place for BiDi handling.
Isn't one of the terminal emulator main tasks to free the application
tedious details of input/output and present a common interface? After
all, it is the terminal emulator and not the application who has more
knowledge about the terminal and the most convenient methods of dealing
with various aspects of the terminal. A terminal emulator that does not
handle its BiDi applications force these applications to deal with BiDi
This is bad because:
(1) It complicates the application with aspects that the application
should not be concerned of (input/output methods).
(2) It also complicates the application because the application has
more limited ways to handle the terminal then the terminal emulator.
(3) It does not help in creating a common application-terminal
interface for BiDi applications. Actually, not only that it does not
help but it also makes it more difficult. Even if the application
programmer is looking for BiDi support it is hard for him to verify the
correctness of his work since this is not natural for him.
This last point can not be over emphasized. Just to give an example
from a few weeks ago:
An Israeli programmer has managed to add Hebrew support for wordtrans
at the application level. He then approached upstream to have it merged
with the main version. However one major obstacle was that upstream had
many difficulties with the verification of the result because he
couldn't tell whether what he got on the screen is a readable Hebrew
However the above short description distorts the situation. The details
are important here: this was all about 3 English words and 3 Hebrew
words. And the whole discussion was under KDE (and maybe Gnome), where
different versions of KDE gave upstream different results. At the end
the Israeli(!) programmer dare wrote `I do not mean to be rude but I
have repeated several times that ...'.
You can follow the thread about it at http://ivrix.org.il/mailing-lists/
ivrix-discuss/2001/11 and http://ivrix.org.il/mailing-lists/2001/12.
The thread is titled `hebrew support for wordtrans'.
> I think mlterm can satisfy such people by disabling BiDi support by
> using command option or configuration file.
> The point is, Shaul, do you think the BiDi support should be enabled
> by default or should be disabled by default?
What are the implications of enabling it by default?
Will it be transparent to applications that are not BiDi aware? Will it
makes them totally unusable? Perhaps it would makes them show some
gibberish here and there but the overall result would be acceptable?
> mlterm: http://mlterm.sourceforge.net/
> Tomohiro KUBOTA <email@example.com>
> "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
Please replace (at-no-spam) with an at - @ - character.
(at-no-spam) is meant for unsolicitate mail senders only.