From: Simon Montagu (smontagu@smontagu.org)
Date: Sun Jan 04 2009 - 05:53:21 CST
Hi Itai,
It's unclear to me whether you applied the Bidi Algorithm manually or
with an existing implementation. I suspect that the cause of the 4 and 3
zigzag in embedding levels is an error in applying rules X10 and W7 of
the algorithm. After rule X9, the embedding levels are:
ivrit 1 2 3 bdika
11111122222111111
There are then three runs:
Run 1 is at level 1, sor is R, eor is L.
Run 2 is at level 2, sor is L, eor is L.
Run 3 is at level 1, sor is L, eor is R.
Then when searching backwards from the European numbers in rule W7, the
first strong type found is sor, which is L, and the type of the numbers
changes to L.
In rule N1, the neutrals (spaces) between the numbers also change to L.
Rules I1 and I2 then have no effect, so the embedding levels do not
change, and after reordering the result is
akidb 1 2 3 tirvi
as expected.
On 1/4/09 2:14 AM, Itai Bar-Haim wrote:
> Hi everyone.
>
> I have a problem with a specific case (small letters - Hebrew, large
> letters - L - LRE, P - PDF):
>
> ivrit L1 2 3P bdika
>
> I expected the result to be:
>
> akidb 1 2 3 tirvi
>
> but the actual result I get when running the algorithm is:
>
> akidb 3 2 1 tirvi
>
>
> The problem I could see was in the embedding levels:
>
> 1111112434341111111
> ivrit L1 2 3P bdika
>
> the 4 and 3 zigzag caused the following (lowering the embedding level
> number of each run for the example):
>
> 1111112333331111111
> ivrit L_1_ _2_ _3_P bdika
>
> 1111112222221111111
> ivrit L_3 2 1_P bdika
>
> 1111111111111111111
> ivrit _1 2 3L_P bdika
>
> 0000000000000000000
> _akidb PL3 2 1 tirvi_
>
> removing the invisible LRE and PDF:
> akidb 3 2 1 tirvi
>
> I think there is something wrong with the initial setting of embedding
> levels in for spaces between the numbers. Am I missing anything here?
>
> Itai.
This archive was generated by hypermail 2.1.5 : Sun Jan 04 2009 - 05:56:22 CST