[Fribidi-discuss] Re: BiDi WINE status and fribidi

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


On Fri, 23 Aug 2002, Omer Zak wrote:

> On Fri, 23 Aug 2002, Shachar Shemesh wrote:
> 
> > Quoting your relevant web page:
> >   Is this a fork?
> >
> > Unfortunately, yes - for the time being. It is my hope that Dov Grobgeld
> > will incorporate the changes made in this version into the next
> > mainstream version of his FriBidi package.
> 
> Sorry, but this information is obsolete and I didn't bother to update the
> Web page.  At the time version 0.1.14 was in use, and I wasn't successful
> in contacting Dob Grobgeld due to technical reasons.
> 
> The version being used now is 0.11.0, and it incorporates my bug fixes
> from the time as well as various enhancements, which should make it easier
> for you to use (including some support for work under MS-Windows).

Just to make pople clear:  0.11.-0 is the version in CVS HEAD 
branch, and 0.10.-5 is the version in CVS STABLE branch, the '-' 
sign is there to mean a pre-release version, so read 0.10.-5 as 
0.10.5pre,  I changed the style since Shachar asked for an 
integral micro version for his Win32 port.

> > >There are some Unicode code points, which cannot be represented in 16
> > >bits, but I believe that WINE can live without supporting those code
> > >points (which would otherwise require surrogates in UTF-16).
> > >
> > That, I'm afraid, is where you are wrong. These codepages are crucial
> > for far east support, and Wine in general cannot live without them. What
> > I am willing to do is add surrogate support to fribidi, however. This
> > shouldn't pose TOO much of a problem, but it means #ifdefs in the code.
> 
> General issue:
> We use flags (in FriBidiEnv) to tailor the FriBidi algorithm to various
> situations.  In general, they should be usable in lieu of #ifdef's.
> However, some people may need a lightweight version of FriBidi, omitting
> code which supports certain flag settings.
> Therefore, it may be necessary to accompany each flag with #ifdef around
> code which implements it.

I really like #ifdefs, they make me feel more powerful ;).  When 
implementing UTF-16, I will handle surrogate pairs too.  It needs 
some #ifdefs, but they are really small.
 
> > >About pointB, I don't have an opinion at the moment.But if it requires
> > >a different behavior of the FriBidi algorithm, maybe this can be
> > >accommodated by adding another flag to FriBidiEnv and have the algorithm
> > >do whatever you want if the flag is set.
> >
> > It requires an override. The way Windows do it is:
> > A. Badly. I couldn't get it to work at all at first, and then work in a
> > most bizar way.
> > B. Providing an array the size of the string specifying overrides (i.e.
> > - the third character is a Hebrew character, no matter what the Unicode
> > tables say). As you need such an array anyways, and as even the Windows
> > function fills this array in after reordering with the missing data, you
> > can use the user supplied array for your own processing. It is this
> > requirement that should be relatively easy to support (but will require
> > interface changes)-:
> 
> Does this mean that MS-Windows does not follow exactly the Unicode
> standard when handling the special directional override character codes?
> 
>                                              --- Omer
-- 
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