[Fribidi-discuss] BiDi WINE status and fribidi

Behdad Esfahbod behdad at bamdad.org
Fri Aug 23 17:02:02 EST 2002


So finally  here is, the lord of all fribidi branches ;) (effects 
of reading "Just for Fun", by Linus Torvalds, these days).

It seems that don't replying is a real good way of getting good 
comments and making other people think on fribidi :).

More below:

On Thu, 22 Aug 2002, Shachar Shemesh wrote:
[snip]
> The main limitations we feel prevent Wine from using fribidi are:
> A. fribidi's use of UTF-32, vs. UTF-16 by Windows.

I have decided to implement UTF-16 myself, no hard work, but of 
course, its a compile time option, like --enable-utf16, and I try 
to rename the output library to fribidi16 or something like that, 
to be able to have both 16 and 32 bit versions installed on a 
machine.

> B. Lack of support for out of bounds overriding of character types (the 
> lpClass parameter of the GCP_RESULTS struct of GetCharacterPlacement. If 
> anyone is interested in the full details - 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_4l84.asp)

If I understand you correctly, you need to be able to state that 
for example, the bidi type for character 'A' should be RTL, 
insteal of LTR.  There are two solutions:

	1. In the next generation interface of fribidi, there is 
a call that does bidi on given bidi types.  So you can get the 
bidi types of string from fribidi, override ones you want, and 
ask it to apply bidi with the given types.

	2. I'm thinking of a global overriding mechanism
(ofcourse through the fribidienv in the next generations), the 
idea is having a simple hash table of overrided character types.  
Its easy to implement.

> Unless we create two distinct implementations of libfribidi, I fear that 
> the best approach for dealing with A is to create a WINE only fork of 
> fribidi.

You can simply patch fribidi for your use, and still do not fork 
it, like the way Owen handles in pango, he has a (huge) patch, 
that he should update to apply on later versions of fribidi.  Its 
a little difficult, but is possible. (BTW, fribidi is more more 
stable now, and it makes future updates easy).

> B is just something to consider if you indeed want to revise 
> the fribidi interface 
> (http://sourceforge.net/mailarchive/forum.php?thread_id=790237&forum_id=3189).

Some points:

	* I'm really busy for about 4 weeks.  It should be two 
long for you to wait, so please try implementing something that 
works, and then we will revise it together when I'm back (yes, I 
will be in a trip to India for TUG'2002).

	* Another question is that should I implement B before 
1.0 or not?  I think I do it, as it's easy to do, and then 
changing the API for 1.0 is not hard.

> Your voices and opinions, please.
> 
>                     Shachar

-- 
Behdad Esfahbod		2 Shahrivar 1381, 2002 Aug 24 
http://behdad.org/	[Finger for Geek Code]

#define is_persian_leap(y) ((((y)-474)%2820+2820)%2820*31%128<31)





More information about the FriBidi mailing list