Re: [webvtt] 6.2.1 processing model handling of bidi [I18N-ISSUE-432]

Registered in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28266 for
feedback by TextTracks CG.

Regards,
Silvia.

On Sat, Mar 21, 2015 at 7:46 AM, Phillips, Addison <addison@lab126.com> wrote:
> I18N comment: https://www.w3.org/International/track/issues/432
>
> 6.2.1 Processing model
> http://www.w3.org/TR/2014/WD-webvtt1-20141111/#h4_processing-model
>
> In section 6.2.1 I find the instruction quoted below. This seems to be trying to determine the base direction, but I don't see other elements of implementing BIDI elsewhere in processing, such as using 'direction' to set the meaning of 'start' and 'end' and I don't see any discussion of handling directional runs in presentation (is that on a different level??)
>
> --
> Apply the Unicode Bidirectional Algorithm's Paragraph Level steps to the concatenation of the values of each WebVTT Text Object in nodes, in a pre-order, depth-first traversal, excluding WebVTT Ruby Text Objects and their descendants, to determine the paragraph embedding level of the first Unicode paragraph of the cue. [BIDI]
> Note
>
> Within a cue, paragraph boundaries are only denoted by Type B characters, such as U+000A LINE FEED (LF), U+0085 NEXT LINE (NEL), and U+2029 PARAGRAPH SEPARATOR. (This means each line of the cue is reordered as if it was a separate paragraph.)
>
> If the paragraph embedding level determined in the previous step is even (the paragraph direction is left-to-right), let direction be 'ltr', otherwise, let it be 'rtl'.
> --
>
> It would be helpful to the author to be able to set the default base direction for a whole WebVTT file to rtl.
>
> 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."
>

Received on Sunday, 22 March 2015 00:19:32 UTC