Re: [I18n]Re: mlterm with BiDi support
This is the reason that I never understood how BiDi support in
the X-level or in the terminal could work. Unfortunately, the
BiDi support must be inserted in a higher level. The question
is if the curses library is enough, or if it must be even higher
up.
Dov
On Fri, Feb 08, 2002 at 08:10:50PM +0330, Behdad Esfahbod wrote:
> Hi,
>
> What do you call a two month delay? late?
>
> On Thu, 27 Dec 2001, Tomohiro KUBOTA wrote:
> > At Thu, 27 Dec 2001 05:28:34 +0200,
> > Shaul Karl wrote:
> > > Behdad wrote:
> > > > 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 think Behdad says that they sometimes need to use non-BiDi-supported
> > terminals such as Linux console. For such cases, libraries such as
> > curses may supply BiDi support, though I don't know this works well
> > or not.
>
> No, this is not what I meant, consider the X equivalents: biditext
> library currently adds bidi support in X server layer, it means that
> applies bidi on all strings that get drawn on the screen, but what's
> the result? With editors, browsers, ..., you need to refresh the
> screen each time you type a letter, you get wrong order, ..., while
> the output from grep works fine in your non-bidi terminal ...
>
> What I mean is that:
>
> 1. When the editor keeps track of cursor, the terminal bidi can't
> work, because the editor thinks different about the current data on
> terminal, speaking in terms of emacs: the glyph matrix of the emacs is
> different from what you see on terminal ('cause the terminal has
> applied bidi on the output of emacs...).
>
> 2. Also libncurses should know bidi, why? answer: the bidi algorithm
> of unicode is a paragraph oriented algorithm, but what does ncurses
> with a paragraph? I guess it breaks it to lines, moves cursor to the
> start of first line, prints it, ... second line, prints it, ..., then
> tries to redraw the menu bar titles, then ...., you know, if you pass
> this data to a paragraph oriented text filter, what you get is somehow
> a random permutation of the input..., try running vim o lynx with bidi
> enables xterm, and play with it to get the idea, while cat, and
> friends work fine. The case is just like the X server bidi support,
> vs. KDE and GNOME support, I guess every UI Toolkit should know about
> bidi, because this is the toolkit that knows the logical boundry of
> different pieces of text.
>
> Yours,
> behdad
>
>
> > For my case, Linux console doesn't support Japanese. Thus, I have
> > lines like:
> >
> > if [ "$TERM" = "linux" ] ; then
> > LANG=C
> > else
> > LANG=ja_JP.eucJP
> > fi
> >
> > in my ~/.bashrc file.
> >
> > ---
> > 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 Esfahbod 19 Bahman 1380, 2002 Feb 8
> <behdad at bamdad dot org> [Finger for Geek Code]
>
> George Orwell was an optimist.
>
>
>
> ----
> Ivrix-discuss list. See http://ivrix.org.il.
> To unsubscribe, please send mail to majordomo@ivrix.org.il with only the
> following line in the message body (NOT SUBJECT!): unsubscribe ivrix-discuss
>
Reply to: