[Bug 28266] [webvtt] 6.2.1 processing model handling of bidi [I18N-ISSUE-432]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28266

--- Comment #20 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to Glenn Adams from comment #19)
>
> > > It would also be helpful if the author could set the base direction for each
> > > cue explicitly, since the Unicode paragraph detection algorithm can be
> > > fooled by a paragraph that starts with a strong LTR character, but is
> > > actually a RTL paragraph (or vice versa), eg. "نشاط التدويل is how you say
> > > 'i18n Activity' in Arabic."
> > 
> > This problem has been acknowledged. However, there is already a means to
> > address this by using the UTF-8 RLO, LRO, RLE and LRE characters. These do
> > explicit directionality overrides in contrast to &lrm; and &rlm; which
> > provide only hints to the algorithm.
> 
> While it is true that each cue's text could be wrapped in a RLE/PDF or
> LRE/PDF pair, this does not actually affect the cue's default
> directionality, but merely the embedding level of the text so wrapped.

If the resulting rendering is correct, what's the difference in it being called
an overall "default directionality" and "the default direction of text on that
embedding level"?


> If there are style properties that apply to the cue as a whole, and those
> properties require the use of a default directionality to resolve their
> computed value, e.g., the computed value resolved from 'start', 'end', etc.,
> then use of Bidi controls in the text will not suffice.

The writing direction in WebVTT is not determined from the cue text, but
through cue settings. The resolution of 'start' and 'end' alignments and
positioning is dependent on the paragraph directionality as determined by BIDI,
which in fact is the direction of the paragraph embedding level, so we're good
on that, too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 1 October 2015 18:52:40 UTC