Re: fribidi_reorder_runs()

Eduardo Castiñeyra <[email protected]> Wed, 15 Feb 2017 18:07:13 +0100
Newsgroups gmane.comp.internationalization.fribidi
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============0298683574==
Content-Type: multipart/alternative;
 boundary="------------5F46EABFC710CD9CE93A5C57"

This is a multi-part message in MIME format.
--------------5F46EABFC710CD9CE93A5C57
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks Behdad!

On 2/8/2017 10:33 PM, Behdad Esfahbod wrote:
> 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ñeyra 
> <[email protected] <mailto:[email protected]>> wrote:
>
>
>
>     On 2/8/2017 7:02 PM, Eli Zaretskii wrote:
>
>             Cc: [email protected]
>             <mailto:[email protected]>
>             From: Eduardo Castiñeyra <[email protected]
>             <mailto:[email protected]>>
>             Date: Wed, 8 Feb 2017 16:59:04 +0100
>
>             On 2/7/2017 5:19 PM, Eli Zaretskii wrote:
>
>                     From: Eduardo Castiñeyra <[email protected]
>                     <mailto:[email protected]>>
>                     Date: Tue, 7 Feb 2017 16:39:01 +0100
>
>                     It turned out that our incorrect way to integrate
>                     fribidi and harfbuzz
>                     (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 an 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
>     <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] <mailto:[email protected]>
>     https://lists.freedesktop.org/mailman/listinfo/fribidi
>     <https://lists.freedesktop.org/mailman/listinfo/fribidi>
>
>
>
>
> -- 
> behdad
> http://behdad.org/


--------------5F46EABFC710CD9CE93A5C57
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks Behdad!<br>
    <br>
    <div class="moz-cite-prefix">On 2/8/2017 10:33 PM, Behdad Esfahbod
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAF63+7V27SUMuu=Ov23U9rGyoOBiJ=tMbHqGFtssafS77a+2mg@mail.gmail.com"
      type="cite">
      <div dir="ltr">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.<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Feb 8, 2017 at 10:20 AM,
          Eduardo Castiñeyra <span dir="ltr">&lt;<a
              moz-do-not-send="true"
              href="mailto:[email protected]" target="_blank">[email protected]</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class=""><br>
              <br>
              On 2/8/2017 7:02 PM, Eli Zaretskii wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Cc: <a moz-do-not-send="true"
                    href="mailto:[email protected]"
                    target="_blank">[email protected]</a><br>
                  From: Eduardo Castiñeyra &lt;<a moz-do-not-send="true"
                    href="mailto:[email protected]"
                    target="_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="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      From: Eduardo Castiñeyra &lt;<a
                        moz-do-not-send="true"
                        href="mailto:[email protected]"
                        target="_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 "surprisingly" 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'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.  See L4 in the UBA
                (a.k.a. "UAX#9")<br>
                description.  It says:<br>
                <br>
                   A character is depicted by a mirrored glyph if and
                only if (a) the<br>
                   resolved directionality of that character is R, and
                (b) the<br>
                   Bidi_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 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.<br>
            <br>
            Behdad proposed an algorithm to reorder the runs ourselves<br>
            <br>
            <a moz-do-not-send="true"
href="https://github.com/behdad/linear-reorder/blob/master/linear-reorder.c"
              rel="noreferrer" target="_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.  Of course we'd rather use the one implemented in
            FriBiDi as soon as it is available. Hence my question.
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                ______________________________<wbr>_________________<br>
                fribidi mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:[email protected]"
                  target="_blank">[email protected]</a><br>
                <a moz-do-not-send="true"
                  href="https://lists.freedesktop.org/mailman/listinfo/fribidi"
                  rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/fribidi</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        <div class="gmail_signature" data-smartmail="gmail_signature">behdad<br>
          <a moz-do-not-send="true" href="http://behdad.org/"
            target="_blank">http://behdad.org/</a></div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------5F46EABFC710CD9CE93A5C57--

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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZnJpYmlkaSBt
YWlsaW5nIGxpc3QKZnJpYmlkaUBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m
cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmliaWRpCg==

--===============0298683574==--