Re: Resolving TextTrackCue issues

On Mon, Sep 9, 2013 at 3:27 AM, Philip Jägenstedt <philipj@opera.com> wrote:

> On Sun, Sep 8, 2013 at 6:02 AM, Glenn Adams <glenn@skynav.com> wrote:
> >
> > On Sat, Sep 7, 2013 at 5:27 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com>
> > wrote:
> >>
> >> I don't follow. Can you give an example of a serialized TTML document
> >> entity ? I thought it was XML and not binary?
>
> > (1) it can be encoded in either UTF-8, UTF-16, or any other encoding, and
> > contains its encoding declaration, so this effectively requires binary
> > (octet stream) transparency;
>
> After parsing TTML, all attributes text nodes in the DOM would already
> be decoded to the internal Unicode encoding (probably UTF-16) so
> exposing any of the text from TTML would not require a binary
> representation.
>

The key phrase here is "after parsing" TTML. One can't take an unparsed,
arbitrary encoded XML file and stuff it into WebVTT metadata text without
parsing (as an entity, entailing decoding bytes as characters) and without
escaping LF/CRs.


>
> > (2) but more problematic, it contains, even if decoded into characters,
> > contains LF and CR, which aren't permitted in WebVTT metadata text;
>
> WebVTT files can contain CRLF line endings and so can script-created
> VTTCues. What does happen is that the WebVTT parser normalizes line
> endings. If one wanted to cram TTML into VTTCue (see below) one could
> do something similar.
>
> >> > 2. Because TTML is not related to VTT, and pretending that TTML is
> >> > WebVTT
> >> > metadata text just  confuses authors and implementers.
> >>
> >> Agreed - some renaming would be necessary. VTTCue could be called
> TextCue.
> >
> >
> > NO. Because VTTCue is not representative of all cue types and simply
> > renaming it serves no purpose. It is still VTT based.
>
> Yeah, exposing TTML using VTTCue doesn't make sense unless the TTML
> rendering algorithm is a strict subset of WebVTT, and I'm pretty sure
> it isn't.
>
> Of course, a browser which doesn't care about rendering TTML properly
> could transform it to some subset of VTTCue, but the whole reason that
> VTTCue was split from TextTrackCue was to allow for other rendering
> algorithms than WebVTT's.
>
> This is going a little bit from the original problem, which is what to
> do with in-band metadata tracks of potentially unknown kind and
> whether or not any browser actually wants to expose subtitles/captions
> to scripts without rendering them.
>
> Philip
>