Re: FriBidi's rendering pipeline (was Re: what encoding? where are the docs?)
Behdad Esfahbod <[email protected]>
| Newsgroups | gmane.comp.internationalization.fribidi |
|---|---|
| Message-ID | <[email protected]> |
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/