Re: Re: Arabic support

--===============0691555472==
Content-Type: multipart/alternative; boundary=000e0cd6a89621c145048f5bcd25

--000e0cd6a89621c145048f5bcd25
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 3, 2010 at 4:25 PM, Eli Zaretskii <[email protected]> wrote:

<- Snipped text ->


> Even if everything I said above is correct, there are complications.
> ABCDE could be inside an embedding with left to right override, like
> this:
>
>  foobar RLO ABCDE PDF
>
> This should be displayed as
>
>  foobar ABCDE
>
> i.e., "ABCDE" is not reordered, but displayed in the logical order, as
> forced by RLO.  Therefore, the reshaped "XYZ" should also be displayed
> left to right:
>
>  foobar XYZ
>
> But, if I understand correctly how composition works, the
> auto-composed sequence in this case will still be just "XYZ", without
> the RLO and PDF control characters.  So the `shape' method of the font
> driver will still see just "XYZ" in the LGSTRING, without the control
> characters, and will reorder "XYZ", which is incorrect.
>
> If we need the `shape' method to reorder glyphs, then in order for it
> do its job correctly, we need to give it the entire bidi context of
> the string we are asking it to reshape.  In the above example, we need
> to tell it about the override directive, i.e. pass it "ABCDE" with
> surrounding RLO and PDF controls.  This flies in the face of the
> current design, which separates reordering from glyph shaping.
>
>
Is that a typo? I think you mean LRO (U+202D) rather than RLO in all cases
above.
(Just commenting, to avoid further misunderstandings).

   Amit

--000e0cd6a89621c145048f5bcd25
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">On Fri, Sep 3, 2010 at =
4:25 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]=
">[email protected]</a>&gt;</span> wrote:<br><div><br></div><div>&lt;- Snipped t=
ext -&gt;</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im"></div>
Even if everything I said above is correct, there are complications.<br>
ABCDE could be inside an embedding with left to right override, like<br>
this:<br>
<br>
=A0foobar RLO ABCDE PDF<br>
<br>
This should be displayed as<br>
<br>
=A0foobar ABCDE<br>
<br>
i.e., &quot;ABCDE&quot; is not reordered, but displayed in the logical orde=
r, as<br>
forced by RLO. =A0Therefore, the reshaped &quot;XYZ&quot; should also be di=
splayed<br>
left to right:<br>
<br>
=A0foobar XYZ<br>
<br>
But, if I understand correctly how composition works, the<br>
auto-composed sequence in this case will still be just &quot;XYZ&quot;, wit=
hout<br>
the RLO and PDF control characters. =A0So the `shape&#39; method of the fon=
t<br>
driver will still see just &quot;XYZ&quot; in the LGSTRING, without the con=
trol<br>
characters, and will reorder &quot;XYZ&quot;, which is incorrect.<br>
<br>
If we need the `shape&#39; method to reorder glyphs, then in order for it<b=
r>
do its job correctly, we need to give it the entire bidi context of<br>
the string we are asking it to reshape. =A0In the above example, we need<br=
>
to tell it about the override directive, i.e. pass it &quot;ABCDE&quot; wit=
h<br>
surrounding RLO and PDF controls. =A0This flies in the face of the<br>
current design, which separates reordering from glyph shaping.<br>
<br></blockquote><div><br></div><div>Is that a typo? I think you mean LRO (=
U+202D) rather than RLO in all cases above.</div><div>(Just commenting, to =
avoid further misunderstandings).</div><div><br></div><div>=A0=A0 Amit</div=
>
<div><br></div></div></div>

--000e0cd6a89621c145048f5bcd25--


--===============0691555472==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
emacs-bidi mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-bidi

--===============0691555472==--