Re: fribidi_reorder_runs()

--===============0827143853==
Content-Type: multipart/alternative; boundary=94eb2c036852b1872c05480b9e88

--94eb2c036852b1872c05480b9e88
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'll try to put it back in FriBidi.  The rollback was necessary because the
original commit was exposing structs that we didn't want to.

On Wed, Feb 8, 2017 at 10:20 AM, Eduardo Casti=C3=B1eyra <
[email protected]> wrote:

>
>
> On 2/8/2017 7:02 PM, Eli Zaretskii wrote:
>
>> Cc: [email protected]
>>> From: Eduardo Casti=C3=B1eyra <[email protected]>
>>> Date: Wed, 8 Feb 2017 16:59:04 +0100
>>>
>>> On 2/7/2017 5:19 PM, Eli Zaretskii wrote:
>>>
>>>> From: Eduardo Casti=C3=B1eyra <[email protected]>
>>>>> Date: Tue, 7 Feb 2017 16:39:01 +0100
>>>>>
>>>>> It turned out that our incorrect way to integrate fribidi and harfbuz=
z
>>>>> (let fribidi reorder all the characters and shape as full LTR in
>>>>> harfbuzz) is "surprisingly" causing problems.
>>>>>
>>>>> The problem is mainly with the parenthesis. It looks like the shaper
>>>>> should flip the direction of the parenthesis when it belongs to a RTL
>>>>> run.
>>>>>
>>>> Shouldn't reordering mirror parentheses if their level is even?
>>>>
>>> AFAIK, parenthesis are neutral, they inherit the direction of the text
>>> surrounding them
>>>
>> Yes, and if the surrounding text is RTL, the parentheses should be
>> mirrored as part of reordering.  See L4 in the UBA (a.k.a. "UAX#9")
>> description.  It says:
>>
>>    A character is depicted by a mirrored glyph if and only if (a) the
>>    resolved directionality of that character is R, and (b) the
>>    Bidi_Mirrored property value of that character is Yes.
>>
>>
> That makes sense. Nevertheless the direction of the parenthesis is just a=
n
> example of why we need that fribidi_reorder_runs function which was what =
my
> question was actually about.
>
> I think that, in a glyph based renderer, changing the direction of the
> parenthesis should be on harfbuzz's roof not fribidi. fribidi's
> responsibility would be limited to reordering the runs and labeling them
> with their level.
>
> Behdad proposed an algorithm to reorder the runs ourselves
>
> https://github.com/behdad/linear-reorder/blob/master/linear-reorder.c
>
> but he also implemented it in FriBiDi and then rolled it back.  Of course
> we'd rather use the one implemented in FriBiDi as soon as it is available=
.
> Hence my question.
>
>
> _______________________________________________
> fribidi mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/fribidi
>



--=20
behdad
http://behdad.org/

--94eb2c036852b1872c05480b9e88
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ll try to put it back in FriBidi.=C2=A0 The rollback=
 was necessary because the original commit was exposing structs that we did=
n&#39;t want to.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Wed, Feb 8, 2017 at 10:20 AM, Eduardo Casti=C3=B1eyra <span dir=
=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">=
[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><span class=3D""><br>
<br>
On 2/8/2017 7:02 PM, Eli Zaretskii wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cc: <a href=3D"mailto:[email protected]" target=3D"_blank">frib=
[email protected]</a><br>
From: Eduardo Casti=C3=B1eyra &lt;<a href=3D"mailto:[email protected]=
m" target=3D"_blank">[email protected]</a>&gt;<br>
Date: Wed, 8 Feb 2017 16:59:04 +0100<br>
<br>
On 2/7/2017 5:19 PM, Eli Zaretskii wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Eduardo Casti=C3=B1eyra &lt;<a href=3D"mailto:[email protected]=
m" target=3D"_blank">[email protected]</a>&gt;<br>
Date: Tue, 7 Feb 2017 16:39:01 +0100<br>
<br>
It turned out that our incorrect way to integrate fribidi and harfbuzz<br>
(let fribidi reorder all the characters and shape as full LTR in<br>
harfbuzz) is &quot;surprisingly&quot; causing problems.<br>
<br>
The problem is mainly with the parenthesis. It looks like the shaper<br>
should flip the direction of the parenthesis when it belongs to a RTL run.<=
br>
</blockquote>
Shouldn&#39;t reordering mirror parentheses if their level is even?<br>
</blockquote>
AFAIK, parenthesis are neutral, they inherit the direction of the text<br>
surrounding them<br>
</blockquote>
Yes, and if the surrounding text is RTL, the parentheses should be<br>
mirrored as part of reordering.=C2=A0 See L4 in the UBA (a.k.a. &quot;UAX#9=
&quot;)<br>
description.=C2=A0 It says:<br>
<br>
=C2=A0 =C2=A0A character is depicted by a mirrored glyph if and only if (a)=
 the<br>
=C2=A0 =C2=A0resolved directionality of that character is R, and (b) the<br=
>
=C2=A0 =C2=A0Bidi_Mirrored property value of that character is Yes.<br>
<br>
</blockquote>
<br></span>
That makes sense. Nevertheless the direction of the parenthesis is just an =
example of why we need that fribidi_reorder_runs function which was what my=
 question was actually about.<br>
<br>
I think that, in a glyph based renderer, changing the direction of the pare=
nthesis should be on harfbuzz&#39;s roof not fribidi. fribidi&#39;s respons=
ibility would be limited to reordering the runs and labeling them with thei=
r level.<br>
<br>
Behdad proposed an algorithm to reorder the runs ourselves<br>
<br>
<a href=3D"https://github.com/behdad/linear-reorder/blob/master/linear-reor=
der.c" rel=3D"noreferrer" target=3D"_blank">https://github.com/behdad/line<=
wbr>ar-reorder/blob/master/linear-<wbr>reorder.c</a><br>
<br>
but he also implemented it in FriBiDi and then rolled it back.=C2=A0 Of cou=
rse we&#39;d rather use the one implemented in FriBiDi as soon as it is ava=
ilable. Hence my question.<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
______________________________<wbr>_________________<br>
fribidi mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">fribidi@=
lists.freedesktop.org</a><br>
<a href=3D"https://lists.freedesktop.org/mailman/listinfo/fribidi" rel=3D"n=
oreferrer" target=3D"_blank">https://lists.freedesktop.org/<wbr>mailman/lis=
tinfo/fribidi</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">behdad<br><a href=
=3D"http://behdad.org/" target=3D"_blank">http://behdad.org/</a></div>
</div>

--94eb2c036852b1872c05480b9e88--

--===============0827143853==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZnJpYmlkaSBt
YWlsaW5nIGxpc3QKZnJpYmlkaUBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m
cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmliaWRpCg==

--===============0827143853==--