emacs-bidi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [emacs-bidi] using fribidi and Pango


From: Behdad Esfahbod
Subject: Re: [emacs-bidi] using fribidi and Pango
Date: Sun, 4 Dec 2005 16:24:28 -0500 (EST)

On Sun, 4 Dec 2005, Tomas Frydrych wrote:

> >> 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.
>
> That is very nice piece of code; for what it is worth, I think this
> would be worth incorporating into fribidi.

Agreed.  I looked into the code too.  Looks very complex, but
then it is expected to be.  Fortunately a lot of data tables and
other stuff can be replaced by FriBidi's structures, chopping
some 500 lines of it I guess.  The rest needs some restructuring.

But then the question is, is the API usable in more than Emacs
only?  I'm personally interested in having a bidi  API that does
not process paragraph at a time, but you give it the range you
are interested in (the range that fits in the screen), and it
will only lookahead as much as needed only.

My recent work in Pango made me believe that writing general
purpose libraries for algorithms is just not easy to get right.
You cannot have an stable general API and high performance
together.  Algorithms to consume low memory and perform fast,
need to integrate into eachother at levels not quite possible by
library APIs.  Even an array containing the input text is being
problematic.  There's always someone asking for UTF-8, one for
UTF-16, another for UTF-32.  Then there are libraries that keep
some kind of struct Char [], that contains more than the text
itself.  You just cannot write a fast low-overhead library to
handle them all.  And you cannot use glib, since too many
projects don't use it, so you need to define all the UTF-8 and
UTF-16 functions yourself, should you go that route.  Not talking
about how hard just finding a 32-bit integer can be...
</rant>


> > 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.
>
> The Pango high level code will not do that (there is only that much that
> can be generalised into a library), but in this regard Emacs is not
> unique; there are other applications that have complex demands which can
> only be satisfied by their own layout engine. However, scripting engine
> can provide a low-level api that makes it possible to plug it into that
> engine. Pango has a low level api that is quite usable and if it does
> not entirely suit your needs as is, Behdad is a very reasonable guy :).
> I am going to shut up now.

Heh,
I'm more interested to see the highlevel PangoLayout object
extended to cover needs of applications like Emacs and AbiWord.
And I'm willing to hear more about those needs :).

> Tomas

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
        -- Dan Bern, "New American Language"




reply via email to

[Prev in Thread] Current Thread [Next in Thread]