Re: [emacs-bidi] using fribidi and Pango

[Eli Zaretskii]

> Date: Fri, 02 Dec 2005 11:24:23 +0000
> From: Tomas Frydrych <address@hidden>
> 
> > Well, you may wish to look at the code I wrote for Emacs:
> 
> I do indeed; could you please point me to the relevant file(s) in the
> repository?

In the emacs-bidi branch of the Emacs CVS, look for src/bidi.c.

> I think the fribidi maintainer would be interested in incorporating that
> into fribidi.

The fribidi maintainer, or at least one of the main contributors to
fribidi, is well aware of this code (he should be reading this list as
we speak).

> There is undoubtedly overhead for bidi, but you do not have to walk all
> the characters all the time, and the cache does not have to be there for
> the entire buffer (I have got very satisfactory results with caching
> single line at a time)

Even a single line could be too much to cache, as lines can be very
long in Emacs.

> and more importantly, the cache does not have to
> be fully refreshed on every operation on the buffer, as many (perhaps
> most) of the normal use cases can be shortcircuted.

Maybe so, but the code I wrote is free from any need to cache
characters.  This makes its interface with the rest of display code
simpler, since any smart caching will need to know a lot about
redisplay optimizations in Emacs (and there's an awful lot of them) to
support them.

> >> 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.
> 
> In which ever way you will achieve that, you will have to do something
> like Pango does.

Sure, but Emacs has so many unique requirements that it's improbable
that Pango (or any other similar package) supports them out of the
box.

> It is relatively easy to do until you hit languages that require
> shaping

I think someone already wrote the code for Arabic to cover this.  It's
not yet in mainstream Emacs, though.

> Whatever you do, if you do not use external script processor you will be
> creating one internally and in the process caching significant amounts
> of Unicode character properties somewhere in your code.

Yes.  But I don't see any reasonable way to avoid that.

> Pango will not provide out of the box answer for you, I am fully
> aware of that, but there might be quite a lot of value to the
> community in helping to improve Pango, rather than reinventing the
> whole thing for emacs alone.

For this, some of the Pango maintainers need to volunteer to learn the
Emacs unique requirements and discuss the various design issues that
will undoubtfully appear once we begin looking into some kind of
mutual support.  Until now, IIRC, no Pango developers expressed any
interest in the Emacs display code, at least not on the Emacs
developers' mailing list, although Emacs supports editing multiple
languages in the same buffer since September 1997, when version 20.1
was released.