> 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 words. 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 PROTECTED]> > 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. _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n