Re: Directionality of Arabic combining characters
- From: Owen Taylor <otaylor redhat com>
- To: dov imagic weizmann ac il
- Cc: gtk-i18n-list redhat com
- Subject: Re: Directionality of Arabic combining characters
- Date: 07 May 2000 17:48:49 -0400
dov@imagic.weizmann.ac.il writes:
> In his letter from 1 May, Owen Taylor wrote:
> >
> > Hi Dov,
> >
> > In fribidi_tables.i, you have:
> >
> > {0x0640, 0x064A, FRIBIDI_TYPE_RTL },
> > {0x064B, 0x0652, FRIBIDI_TYPE_ON },
> > {0x0660, 0x0669, FRIBIDI_TYPE_AN },
>
> The file fribidi_tables.i was automatically created by the script
> CreateGetType.pl from the file UnicodeData.txt . The current algorithm
> was based on a working draft of the algorithm and the accompanying
> version of the UnicodeData.txt file was 2.1.8 . Since then the version
> has been upgraded and this file has changed quite a lot. Even so, in
> the version of UnicodeData.txt from 10 Sep 1999, the range of
> characters U+064B - U+0652 now has the bidi classification NSM - non
> spacing mark.
I looking at the tables and rules in version 2.0 of the standard -
so it was quite possibly considerably out of date. (I've since
obtained a copy of Version 3.0 but haven't gone back and checked
this stuff.)
> Actually, this should be taken care of the rule W1 in the algorithm:
>
> W1. Examine each non-spacing mark (NSM) in the level run, and
> change the type of the NSM to the type of the previous
> character. If the NSM is at the start of the level run, it will
> get the type of sor.
>
> Indeed I have not included this rule in fribidi. It turns out it
> cannot be included until I have updated fribidi to the latest Unicode
> algorithm... (See below)
OK - that sounds like a reasonable way for it to work.
> I really must admit that fribidi isn't very complient to the UniCode
> bidi algorithm any more. It is based on an old working version of the
> algorithm and it hasn't been updated to the spec. Further it still
> doesn't include explicite override characters. This is one of the
> reasons why the Bidi-Mozilla project chose the IBM ICU algorithm over
> fribid. I really should update FriBidi, but as usual I am in a
> chronical state of lack of time for free software activities. 8-(
Well, I can't claim to have loads of time myself, but I may be able to
find a bit of time to look into this. (I also intend to look at doing
a bit of work to speed fribidi up - it takes up something like 20% of
the time spent to layout a large amount of text with Pango.)
Switching to using the ICU code isn't really an option due to
licensing issues, and Mark Leisher's library doesn't seem to be any
more compliant than fribidi from his tests.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]