Re: [I18n]Re: mlterm with BiDi support
On Thu, 27 Dec 2001, Shaul Karl wrote:
> > 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 otherside, 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 beas 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 positionof 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 ashis 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)?
I believe that we all agree that a bidi terminal will solve the problems
of command-line programs. However full-screen programs may do more
complicated manipulations of the text.
Consider the following:
ONE RTL SENTENCE AND ANOTHER RTL SENTENCE
IN A "TEXT BOX" IN A SEPERATE BOX
A simple bidi terminal would get this thing wrong (if you stuff in some
LTR chars, at least) because it will mix the texts of the two boxes.
The progrm that draws this has to know about the existance of the
separate boxes.
As I said before, a simple bidi terminal is on many times still a good
approximation of the behaviour that the user wants even in such complex
cases.
>
>
> > 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 speakershave
> > > 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 ofRTL languages and I think
> > > native speakers' opinion should be respected.
--
Tzafrir Cohen
mailto:tzafrir@technion.ac.il
http://www.technion.ac.il/~tzafrir
Reply to: