Re: WebVTT bidi: should a cue be allowed to contain more than one paragraph?

Thanks, this is great!

One thing, though. As far as I can see, the WebVTT spec does not say that
the cue is supposed to be *rendered* in accordance with the Unicode bidi
algorithm, and more specifically that its P3 (i.e. first strong character)
determines each paragraph's base direction. (Currently, the spec mentions
the bidi algorithm's paragraph level steps effectively just for the purpose
of resolving cue alignment. It does not say anything about the rendering,
i.e. visual ordering of the characters.) The bidi algorithm allows higher
level protocols to override P3, as is the case almost everywhere in HTML,
for example. It is important that implementers realize that in WebVTT there
is no higher level protocol, and thus P3 should apply, and (bidi-aware)
users know what to expect and how they can make use of it.

Aharon

On Wed, Apr 25, 2012 at 12:17 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 7 Dec 2011, Aharon (Vladimir) Lanin wrote:
> >
> > The WebVTT cue text rendering rules currently require applying "the
> > Unicode Bidirectional Algorithm's Paragraph Level steps" to a cue's text
> > in order to "determine the paragraph embedding level of a cue", which is
> > then used to determine the cue's direction (LTR or RTL), which is then
> > used as the basis for the cue's alignment ("start" or "end"). These
> > "Paragraph Level steps"
> > (http://unicode.org/reports/tr9/#The_Paragraph_Level) start with a
> > requirement to "split the text into separate paragraphs", where the
> > "paragraphs are divided by the Paragraph Separator or appropriate
> > Newline Function". This is referring to the Unicode characters PS
> > (U+2029), LF, CR, NEL (U+0085), and a few others.
> >
> > Now, a cue's text is explicitly permitted to contain LF characters,
> > which, in Unicode Bidirectional Algorithm terms, separates paragraphs; I
> > imagine that other paragraph-separating characters are also allowed. So,
> > it would seem then that a cue can contain several (bidi) paragraphs.
> >
> > However, the WebVTT spec currently apparently does not want that to be
> > the case, and goes on to say that the cue text "represents a single
> > paragraph". It is this restriction that currently allows it to talk
> > about "the paragraph embedding level of a cue" (emphasis on "the"), and
> > thus the direction of a cue.
>
> Right.
>
> I have fixed this as described below.
>
>
> > I find this specification problematic in several ways:
> >
> > 1. The Unicode Bidirectional Algorithm states that "Paragraphs may also
> > be determined by higher-level protocols: for example, the text in two
> > different cells of a table will be in different paragraphs." IMO, this
> > allows a higher level protocol - like WebVTT - to introduce paragraph
> > boundaries besides those determined by the paragraph-separating
> > characters. I am not at all sure that it allows a higher-level protocol
> > to ignore paragraph boundaries already present in the cue text, which is
> > implicit in WebVTT's insistence that a cue's text "represents a single
> > paragraph".
>
> I read the text more literally -- higher-level protocols can determine
> what's a paragraph. But this no longer matters, as described below.
>
>
> > WebVTT can, of course, get rid of the paragraph-separating LFs (etc.) by
> > replacing them with other characters (e.g. LS, U+2028) before handing
> > the text over to the algorithm, but the WebVTT spec does not say to do
> > so.
>
> I suppose we could say that, but it would be a bit weird. If the goal is
> to just treat everything as one paragraph (which it isn't; see below), it
> seems simpler to just say that there's one paragraph, rather than try to
> mutate fictional strings just for the purpose of "tricking" another
> algorithm. If we agree that we can have the effect, why not just describe
> the effect?
>
>
> > 2. The WebVTT spec is unclear on whether the direction determined for
> > the cue is only to be used as a basis for alignment, or if the cue text
> > is actually to be *rendered* as a single paragraph in that direction.
> > Please note that paragraph boundaries, and thus paragraph direction, are
> > crucial to the correct display of bidirectional text. For example, let
> > us consider the following text, where we represent RTL characters with
> > uppercase Latin letters:
> >
> > THE FOOD WAS GOOD. HERE IS THE ADDRESS:
> > 50 main st.
> >
> > I am assuming an LF between the two lines. The correct visual ordering
> > for this text, as defined by "the Unicode Bidirectional Algorithm's
> > Paragraph Level steps" is then (ignoring the issue of alignment):
> >
> > :SSERDDA EHT SI EREH .DOOG SAW DOOF EHT
> > 50 main st.
> >
> > Note that the first line's colon is displayed on the left end. That's
> > because the first line is an RTL paragraph (as determined by the
> > "paragraph level steps" because it starts with an RTL character). Also
> > note that the second line is an LTR paragraph. If the two lines were to
> > be lumped into a single RTL paragraph, e.g. by replacing the LF with an
> > LS, the result would be rather different:
> >
> > :SSERDDA EHT SI EREH .DOOG SAW DOOF EHT
> > .main st 50
> >
> > Is this what the WebVTT spec currently requires? Or does it just want
> > the correct display above, except with both lines aligned the same way?
>
> The firt rendering above was the intended rendering.
>
> I've updated the spec to not bother with the complication in the bit you
> quote at the top of this e-mail. Since that text was only used to pick an
> initial direction for the purposes of alignment, it doesn't matter if we
> split it into paragraphs or not. This removes the confusion, leaving it
> just up to CSS to define the rendering, which is what I intended.
>
>
> > 3. I believe that there are use cases that require allowing a cue to
> > contain more than one (bidi) paragraph. For example, there at least used
> to
> > be a widespread practice in Israel for Hebrew-language films to come with
> > subtitles that gave the dialogue in both the original Hebrew and in
> English
> > translation, simultaneously on separate lines.
>
> I don't think this use case should be addressed by line breaks; it should
> be addressed by having two separate WebVTT files.
>
>
> > For these reasons, I would suggest to do away with the concept of cue
> > direction. A cue should be allowed to contain many (bidi) paragraphs,
> > and each paragraph to determine its own direction. So, what do we do
> > with alignment? Well, we could simply allow "start" and "end" to align
> > each paragraph independently. If that is problematic (and I am not sure
> > that this is actually the case), we could re-define "start" and "end" to
> > mean the start and end side of the first non-empty paragraph. And if we
> > wanted the application to decide which way to do it, we could define
> > additional alignment values, e.g. "first-start" and "first-end" in
> > addition to "start" and "end".
>
> I think using the first paragraph is fine.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>