Dynamically linking with a Unix library - or not

[Behdad Esfahbod]

On Wed, 19 Jun 2002, Shachar Shemesh wrote:
> Behdad Esfahbod wrote:
> 
> >I wonder if WINE already has bidi tables of unicode too, if it 
> >has, no problem using it.
> >
> Wrong, I'm afraid. The WINE BiDi table only has the information as 
> defined in Window's GetStringType function. Quoting:
> Name Value Meaning
> *Strong*
> 
> C2_LEFTTORIGHT 0x0001 Left to right
> C2_RIGHTTOLEFT 0x0002 Right to left
> *Weak*
> 
> C2_EUROPENUMBER 0x0003 European number, European digit
> C2_EUROPESEPARATOR 0x0004 European numeric separator
> C2_EUROPETERMINATOR 0x0005 European numeric terminator
> C2_ARABICNUMBER 0x0006 Arabic number
> C2_COMMONSEPARATOR 0x0007 Common numeric separator
> *Neutral*
> 
> C2_BLOCKSEPARATOR 0x0008 Block separator
> C2_SEGMENTSEPARATOR 0x0009 Segment separator
> C2_WHITESPACE 0x000A White space
> C2_OTHERNEUTRAL 0x000B Other neutrals
> *Not applicable*
> 
> C2_NOTAPPLICABLE 0x0000 No implicit directionality (for example, control 
> codes)
> 
> 
> If that's enough - great. I was under the impression this is not enough 
> for 3.0 Unicode implementation.

You can have a look at 3.0 types at fribidi_types.h, they are 19, 
which 5 are explicit bidi marks, so there should still be 
something missing, but no problem to use them, really easy for 
fribidi.

> >>As for compiling Fribidi with UTF-16 - from what I understood from what 
> >>you said before, such a thing may cause reordering problems if Fribidi 
> >>decides, for whatever reason, that a surrogate character needs to be 
> >>right to left. I am not 100% familiar with the bidi algorythm yet, but 
> >>won't marking all surrogate forms (both slices) as strong left to right 
> >>solve this problem?
> >
> >The problem you are talking about will show itself when some one 
> >use RLO..PDF pairs (override embeddings) over some surrogate 
> >pairs, but this is not the main problem, I can hach fribidi to 
> >take care of surrogates and reorder them back if needed (really 
> >easy), the real problem is that when using UTF-16, fribidi will 
> >assume all surrogate characters LTR (strong left to right), but 
> >there *are* non-LTR characters there already (like language 
> >tags), and it may cause to different renderings.  If you want 
> >conformance, UTF-32 is needed ;-(.
> >
> Hmm. Ok, I'll write a mental note to look at it later.
> 
> >>If not, we can always put in special handling that reorders surrogates 
> >>as a pair.
> >>
> That sounds like the ultimate solution? If we already implement 
> re-reordering for wrongly ordered surrogates, we don't have to mark them 
> all as strong LTR. Right?

Ok, we will do this, but if not LTR, what other type?  LTR is the 
default type for all undefined chars and so, and really the best 
huristic...

> >>            Shachar

-- 
Behdad Esfahbod				29 Khordad 1381, 2002 Jun 19 
http://behdad.org/			[Finger for Geek Code]

Humor in the Court:
...
Q:	Have you been there until you left?