Re: [MEDIA_PIPELINE_TF] ISSUE-34: ViewPort-Support

On Thu, Aug 11, 2011 at 7:35 PM, Cyril Concolato
<> wrote:
> Hi Sylvia,
>> Can you fill the TextTrack object and the cues from a SVG? As long as
>> you can make a mapping, it's possible. If the format doesn't fit with
>> the elements, then it's an orthogonal concept that won't fit the bill.
> Reading it says:
> "A text track consists of:"
> * "The kind of text track": would apply to SVG tracks
> * "A label": would apply to SVG tracks
> * "A language": would apply to SVG tracks
> * "A readiness state": would apply as well
> * "A mode": same
> * "A list of zero or more cues"
> A Cue is defined as:
> * "An identifier": applicable to SVG tracks
> * "A start time"/"An end time":
> As such SVG does not define frame-based content as Flash would do or other
> subtitling formats, but you can define frame-based content such as:

This is one of the major requirements. Trust me - SVG won't fit the
bill as a time-aligned data format. And browsers won't implement it.
But you can always try a JavaScript implementation to prove me wrong.


> * A pause-on-exit flag:
> not sure what it means but seems applicable
> * A writing direction: when restricted to unidirectional text content, it
> would be applicable but I don't see it in the TextTrackCue object
> (
> * A size:
> not sure I understand why it's not 2 numbers but it could match the SVG
> width (also not in the interface)
> * The text of the cue:
> if the SVG animation contains text, it could be passed, if not, could be an
> empty string (or the content of a <desc> element) if required.
> The active flag: applicable
> The display state: applicable
> What I'm trying to say is that it seems very restrictive to limit the track
> element to pure text tracks. It disables interesting use cases (synchronized
> graphics overlay) while options to do it are there with SVG, already
> implemented in browsers.
>> In my understanding, SVG has a complex DOM that goes far beyond what
>> TextTrack is capable of representing.
> I don't get this point. The definition of a TextTrack element should not
> care about the expressiveness of the language used to represent the text
> content as long as this language can be mapped to the TextTrack features: if
> it has graphics or not, if it can do bold/italic or not, if it can do bidi
> text or not ...
>> So, I think it's too rich a
>> format for the feature.
> "Oh I don't want your color TV, I just need a black-and-white one".
>> Of course you can always throw any format at a HTML element.However,
>> if browsers don't support it, you can only deal with it through
>> JavaScript - so it's not a standardised feature and not really
>> relevant to the W3C.
> SVG is not any format. It's a W3C format. I think it's relevant.
> Cyril
> --
> Cyril Concolato
> Maître de Conférences/Associate Professor
> Groupe Multimedia/Multimedia Group
> Telecom ParisTech
> 46 rue Barrault
> 75 013 Paris, France

Received on Thursday, 11 August 2011 10:35:50 UTC