Re: [emacs-bidi] using fribidi and Pango

[Eli Zaretskii]

> Date: Thu, 01 Dec 2005 20:00:50 +0000
> From: Tomas Frydrych <address@hidden>
> 
> > I once wrote here the reason: Pango, like fribidi, is a batch-mode
> > reordering library: you hand it a buffer with text and it returns it
> > reordered for display.
> 
> This is not really to do with Pango or fribidi, but with the nature of
> the bidirectional problem. The Unicode bidirectional algorithm requires
> text of entire paragraph as an input, and you will not get satisfactory
> results otherwise.

Well, you may wish to look at the code I wrote for Emacs: modulo any
remaining bugs, it gives satisfactory results and implements the full
UAX#9 algorithm.  It is true that the Unicode algorithm's description
is heavily biased in favor of batch reordering, but that doesn't mean
it couldn't be serialized.  The fact is that I succeeded doing that.

> > By contrast, Emacs needs a reordering function that could be called
> > repeatedly, and will on every call return the next character in the
> > visual order.  This is because the Emacs display engine walks the
> > buffer one character at a time and decides how to display it based on
> > data structures built by the application.
> 
> You can do that easily with fribidi; the fribidi_log2vis() function
> generates a map that allows you to translate logical index into a visual
> one, and you can use it to walk over your buffer.

The initial code to support bidi, written by Handa-san and others at
m17n.org, did something like that.  However, Gerd Moellmann, the
person who wrote the current Emacs display engine, objected to using
such code, since it in effect caches (e.g., in the map you mentioned)
portions of the buffer, and that caching adds a significant overhead
to display engine code.  Emacs has so many display-related features
that walking all the characters in the portion of the buffer that is
shown on the screen makes redisplay unbearably slow.  That is why the
display code has many special cases that optimize it in most practical
situations (the simplest ones being cursor movement and insert/delete
a single character).  Any code that needs to traverse large portions
of the buffer to create a cache of some kind will slow down these
simple cases too much.

> (AbiWord, which too
> has complex data structures associated with its text buffer, uses
> fribidi without any great difficulties.).

I doubt that any other editor out there comes close to Emacs in the
amount of display-related features.  Plus, Emacs needs to run over
remote logins with slow speed and still be reasonably fast.

> It really boils down to how much i18n matters, but you will not get
> decent support for 'exotic' languages unless you do use something like
> Pango.

I don't know what is your value of ``exotic'', but Emacs supports many
languages for several years now, since Emacs 20.1.