Re: [I18n]Re: mlterm with BiDi support
Hi,
I'm a native persian speaker, have wrote many parts of fribidi
library, and also working on console bidi, as all of you agree,
almost all command line tools (like cat, tr, grep, ...), should do
nothing about bidi, and on the other side, their output on terminal
should be readable, then bidi is necessery on terminal, this also
happens for all applications that are subject to gnu translation
project, I mean that when I put my persian message files there, I
should be able to get right messages in persian.
But not all the time console can handle bidi, the application level
bidi should be used where the application is to be run on a console
(and say, not redirected to a file...) and keeps track of cursor
position, does some ansi escape codes to move cursor, ..., like
browsers, editors, menu bars, ....
What we have found is to enable the bidi on terminal, ask applications
that support bidi, to send a bidi-off escape code to terminal, and do
the stuff themselves, for example, libncurses, should support bidi and
turn the terminal bidi off on initscr()...
Feel free to ask.
Yours,
Behdad
On Wed, 26 Dec 2001, Tomohiro KUBOTA wrote:
> Hello,
>
> At Mon, 24 Dec 2001 18:50:19 +0200,
> Shaul Karl wrote:
>
> > 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.
>
> Thank you for your clear opinion. Though I fully agree the logic of
> your opinion, I thought it was not sufficient. I wanted to know how
> _native_ speakers of Hebrew and Arab think. (Sometimes logically
> perfect opinion annoys native speakers because native speakers have
> their own way to do and tradition, which may be somewhat irrational
> but should be respected.)
>
>
> > > 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?
>
> Enabling BiDi never make mlterm unusable for non-BiDi people.
> I cannot feel even speed down because of BiDi. I think there are
> no reasons to disable BiDi.
>
> FYI, there are some people who thinks BiDi should be supported not
> by terminal emulators but by applications.
> http://www.pps.jussieu.fr/~jch/software/luit/
> http://www.cl.cam.ac.uk/~mgk25/unicode.html#xterm
> However, they are not native speakers of RTL languages and I think
> native speakers' opinion should be respected.
>
> ---
> Tomohiro KUBOTA <kubota@debian.org>
> http://www.debian.or.jp/~kubota/
> "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
> _______________________________________________
> I18n mailing list
> I18n@XFree86.Org
> http://XFree86.Org/mailman/listinfo/i18n
>
--
Behdad
5 Dey 1380, 2001 Dec 26
[Finger for Geek Code]
Reply to: