FriBidi's rendering pipeline (was Re: [FriBidi] what encoding? where are the docs?)

[Behdad Esfahbod]

On Wed, 21 Sep 2005, Shachar Shemesh wrote:

> So if, say, in Wine, I'm asked to not perform shaping, I just skip the
> last call right before the reordering? I like.

Yes, but that means you don't get any mirroring.  The
fribidi_shape calls fribidi_shape_arabic and
fribidi_shape_mirroring, both of which can be turned on/off
easily.

> >The whole Arabic part is optional, needless to say.
> >
> So long as we don't get anyone writing for Hebrew and missing out on
> these, that's fine. Is the traditional "log2vis" simply calling the new
> functions? I couldn't manage to figure it out (yes, I did pull the CVS
> sources, but I didn't have a whole lot of time to invest in it).

Yes, in fact I figured out the whole pipeline by looking at the
fribidi_log2vis implementation in lib/fribidi.c.  But do not
forget the problem with fribidi_log2vis, it only works for
paragraphs rendered into one line.  No line breaking step.  So we
really want to let fribidi_log2vis fade away.  I'm fine defining
two convenience functions instead, one for before line-breaking,
one for after.


> >  The good
> >thing about this very low-level and verbose API is that you have
> >full control over the data flow and can change data in the middle
> >steps, if need be.  For example, after getting the bidi types,
> >you can go on and change the types for new line characters to
> >make them line breaks, and two consecutive new line characters
> >paragraph separators.
> >
> Actually, and I mentioned it in the past (which probably triggered the
> change in the first place) Windows has an obscure and rarely used API by
> which you can actually override the types.

Yes, I remember that.  And I've been thinking about adding an API
to change be able to override types, but I don't see it crucial
at this time.  Part of the reason is that I'm thinking about this
other project, as part of project giulia, the GNU
Internationalization & Unicode LIbrary & Applications, that we
are starting to develop
(http://mces.blogspot.com/2005/09/vote-for-your-future.html),
which is about wrapping the Unicode Character Database.  When
daydreaming, I see FriBidi becoming one of the many libraries of
giulia, and using the UCD wrapper there.  We probably will have a
line-breaking library too.  The idea is to have well-integrated
yet separate small libraries, that can be used separately, or in
orchestra together.  Anyway, I see overriding Unicode data in the
UCD wrapper more fit...


> >I like to make mirroring verbose too, such that you call
> >fribidi_get_mirroring on the str and pass the result to
> >fribidi_shape, but I'm not sure it's a good idea, since what a
> >hypothetical fribidi_get_mirroring returns, practically replaces
> >the original string.  In other words, mirroring is really part of
> >the shaping process itself.
> >
> I agree. We need to be able to turn it off, but seperating it is not
> crucial IMHO.

Agreed.

> Let's remeber that we need this API to be fast, as well as functional.

Speed is guaranteed so far, my only concern is as I mentioned,
the temporary memory usage.  That's not important at all on
desktop systems though.

>        Shachar

--behdad
http://behdad.org/