- From: <bugzilla@jessica.w3.org>
- Date: Sun, 22 Mar 2015 00:18:26 +0000
- To: public-texttracks@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28266
Bug ID: 28266
Summary: [webvtt] 6.2.1 processing model handling of bidi
[I18N-ISSUE-432]
Product: TextTracks CG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: WebVTT
Assignee: dave.null@w3.org
Reporter: silviapfeiffer1@gmail.com
QA Contact: public-texttracks@w3.org
CC: philipj@opera.com, silviapfeiffer1@gmail.com
Feedback by Addison Phillips from W3C I18N group:
http://lists.w3.org/Archives/Public/public-tt/2015Mar/0065.html
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."
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 22 March 2015 00:18:27 UTC