[Fribidi-discuss] BiDi WINE status and fribidi

[Behdad Esfahbod]

On Sat, 24 Aug 2002, Shachar Shemesh wrote:
> Behdad Esfahbod wrote:
> >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.
> The second part (having both installed simultaniously) is an extremely 
> important one.

Ofcourse.

> >>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.
>
> No, that's not it.
> 
> If the string "car in hebrew is said CAR" would normally get 
> "LLLNLLNLLLLLLNLLNLLLLNRRR", I want a user to be able to override, say, 
> the first word, saying "RRRdddddddddddddddddddddd" (where "d" means 
> "don't care"), resulting in fribidi treating the sentance as 
> "RRRNLLNLLLLLLNLLNLLLLNRRR". Notice that the character "a" appears in 
> both the first "car", and is being treated as "R", and in "said", and is 
> treated as "L" (because it was not overriden).

Ok, its the easiest request you can ever have.

> The interface must also allow the user to get back the final 
> classification (regardless of whether he overrided it or not).

Wait for it a few days.

> One last thing is that the user must be able to provide classification 
> to the character right before and right after the string (I have only 
> seen any reference to it in the 3.0 standard, but have not read the 3.2 
> standard yet. In 3.0 this affects, for example, W2).

You should insert two characters yourself.

> >  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.
>
> That would do it. Rember, I am very skeptic about the chances of anyone 
> actually using this feature, and so there is no need to change the 
> design (for example - un-RLE the string) just because of this 
> requirement. A seperate function should exist that does that, but that 
> function has to be neither memory nor CPU efficient, as it is not in the 
> main path of execution.
> 
> >	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.
>
> Like I tried to explain - that won't do.

But I like it, it's powerful.

> >>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).
> >
> If we create a seperate utf-16 fribidi, that will not be necessary.

> >>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).
> >
> I will start working on UTF-16 support (once that's in, UTF-8 shouldn't 
> be much of a problem, making conversions of any kind unnecessary. I'm 
> begining to think maybe packaging fribidi16 seperately is not such a 
> good idea after all, but that's up to the packgers). When you come back, 
> we'll see where I got to, and you can decide whether my code is worthy 
> of merging, or would you rather start from scratch yourself ;-)

Ok ;)

> >	* 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.
>
> If it's easy, fine. Don't fuss too much over it, however, as even 
> Alexander accepts that this is not a high priority issue. He merely 
> states that he will not create dependancy on a library that will NEVER 
> solve all of our problems.

Ok, then I will solve the class problem first.
 
>                         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)