Re: Problems with BidiCharTest.txt

That's another argument to deprecate the use of RLE/PDF (or embedding mode)
in favor of the more recent isolating mode (which causes the text just
after the isolated text to not inherit the direction context of the last
inner content, as it occurs here with parentheses that cannot match the
same context before a RLE, but would match within the same context with the
isolation mode).

The isolation mode is also the one strongly recommended by default for
<bdi> elements in HTML, but legacy browsers still don't have support for
isolation mode and were mapping <bdi> element by default using the legacy
embedding mode which has such caveats. So the specification is correct, it
reproduces the legacy behavior as it was initially defined (and did not
change) for RLE/PDF.

2017-07-16 19:09 GMT+02:00 Eli Zaretskii via Unicode <unicode_at_unicode.org>:

> > Date: Sun, 16 Jul 2017 07:13:02 +0300
> > From: Dov Grobgeld via Unicode <unicode_at_unicode.org>
> >
> > While implementing UAX#9 for Unicode 6.3 (and beyond) in FriBidi, I'm
> trying to pass all the tests of
> > BidiCharacterTest.txt , and I'm having problem understanding a few of
> the tests that to me appear to
> > contradict the spefication. The problematic lines in
> BidiCharacterTest-10.0.0.txt are the tests on lines 262,
> > 263, and 264.
> >
> > Let's consider test from line 262:
>
> (I believe you meant line 264.)
>
> > Dir: RTL
> > Input: a ( b <RLE> c <pdf> ) _ 1
> > Level: 2 2 2 x 4 x 1 1 2
> >
> > The problem I'm having is that the first opening bracket is assigned
> level 2 and the closing bracket level 1.
> >
> > This seems to contradict the three rules N0.b, N0.c.1, and N0.c.2 in the
> specification that all describe
> > overriding the type of both brackets with either the embedding or the
> opposite direction. The only case we can
> > possibly get different levels (correct me if I'm wrong!) is if rule N0.d
> is applied and the brackets retain their
> > neutral status until they are resolved in subsequent rules.
>
> The example is correct, IMO. (FWIW, Emacs produces the same reordered
> display as expected by the test.) I think the effect you mention is
> produced by the RLE..PDF embedding: it causes the opening and the
> closing parentheses to be in 2 different isolating run sequences, see
> examples in BD13. Bracket pairs are processed as such only if they
> are in the same isolating run sequence. Try the same test without the
> RLE..PDF part, and you will see the result you expect.
>
Received on Sun Jul 16 2017 - 14:29:07 CDT