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

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 
from the
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 
by themselves.
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 <kubota@debian.org>
> http://www.debian.or.jp/~kubota/
> "Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/


    Shaul Karl
    email: shaulka(at-no-spam)bezeqint.net 
           Please replace (at-no-spam) with an at - @ - character.
           (at-no-spam) is meant for unsolicitate mail senders only.

Reply to: