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, ....
>
I have much less experience then the honorable writer of the original
message.
Yet I do think that writing Hebrew applications should be as easy as
writing ASCII ones. And by that I mean that one should be able to
output to the terminal an Hebrew paragraph and have the terminal print
it in a right to left direction, including starting another line of
text at the rightmost position of the line when the previous line is
filled up. Just as
printf("Suppose this is a very long English text.\n");
would wrap at the rightmost position of the terminal and continue at
the leftmost position of the next line without the programmer
intervention so does an Hebrew text would wrap at the leftmost position
and continues at the rightmost position of the next line. Further more,
we are talking about BiDi here which means that LTR languages (and
numbers) that are embedded in the Hebrew text should be printed in this
Hebrew message in their natural order and vice versa.
Putting it otherwise, an Hebrew speaker student who just start to learn
to program should be able to write his simple terminal based programs
just as easily as his counterpart who speaks `ASCII'. I guess he will
have to use wchar for that but other then this I would like him to be
as little concerned as possible due to his RTL needs. Moreover: he
should be able to display and get as input multi lingual text with
easily.
> 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()...
>
Can you explain what do you mean by `libncurses, should support bidi'?
Why not having the BiDi stuff centralized at one point (the terminal)
instead of having it spread across many (ncurses, slang, libraries for
text only processing)?
> 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]
>
--
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: