Re: ISSUE-446: Should be a subset of IMSC1 [TTML WebVTT mapping note]

> On Sep 23, 2015, at 15:55 , Pierre-Anthony Lemieux <pal@sandflow.com> wrote:
> 
> Hi David and Nigel,
> 
> For one thing, as mentioned in the ticket, selecting an existing
> profile of TTML as a starting point simplifies the mapping task, e.g.
> no need to consider #markerMode or #pixekAspectRatio. In addition, in
> the case of IMSC1, it also allows (limited) support of CSS features
> like background-image, not available in vanilla TTML1.

ah, OK.  I guess we’re looking down different ends of the telescope.

I sort-of assumed that anything that is in the (small) VTT can be done in the (larger) TTML, and hence we’d achieve full VTT coverage by suitably choosing from TTML.  But you’re right, we might discover that there are edge-case features of VTT that are not matched in common TTML profile(s).

Then we say “if you are authoring in TTML, stay within this profile for the best opportunity to convert to VTT” and also “if authoring in VTT, don’t use <these features> for the best opportunity to convert to TTML”.


> 
> Best,
> 
> -- Pierre
> 
> On Wed, Sep 23, 2015 at 3:49 PM, David Singer <singer@apple.com> wrote:
>> 
>>> On Sep 23, 2015, at 4:10 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
>>> 
>>> I disagree that the T2VP profile should be deliberately constrained to be
>>> a subset of IMSC1, because it would be too limiting and wasn't specified
>>> in the charter description of this Note.
>> 
>> I’m with Nigel.  Well, mostly. No, no, I support him.
>> 
>> Let’s work out the best mapping, and then if the mapped part of TTML is not cleanly part of a current profile, think about how to handle that case. So I am sort of with both of you: I don’t want to constrain the mapping work a priori, but I also don’t want to emerge with a needless mismatch a posteriori.
>> 
>>> 
>>> I do agree that if there are significant things that prevent IMSC 1 from
>>> being mappable to WebVTT then we should look at the discrepancies and try
>>> to reconcile them. I also would not object to an additional set of
>>> constraints that explain what limitations would apply to WebVTT in order
>>> to convert it to IMSC 1, extra to what could be done if mapping to TTML1
>>> more generally.
>>> 
>>> Some obvious things that aren't in WebVTT but are constraints of IMSC 1
>>> that I do not think we need to carry over are the reference fonts, the
>>> simultaneously active region limit and the HRM.
>> 
>> Yup.
>> 
>>> 
>>> Nigel
>>> 
>>> 
>>> On 23/09/2015 05:51, "Timed Text Working Group Issue Tracker"
>>> <sysbot+tracker@w3.org> wrote:
>>> 
>>>> ISSUE-446: Should be a subset of IMSC1 [TTML WebVTT mapping note]
>>>> 
>>>> http://www.w3.org/AudioVideo/TT/tracker/issues/446
>>>> 
>>>> Raised by: Pierre-Anthony Lemieux
>>>> On product: TTML WebVTT mapping note
>>>> 
>>>> The profile/authoring guidelines specified in the document should be a
>>>> subset of IMSC1:
>>>> 
>>>> - it helps narrow down the set of features to be supported, e.g. no need
>>>> to support #markerMode
>>>> - it simplifies the job of implementers who are already supporting IMSC1
>>>> 
>>>> Features have been deemed necessary but are not in IMSC1 should be
>>>> considered for addition there.
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -----------------------------
>>> http://www.bbc.co.uk
>>> This e-mail (and any attachments) is confidential and
>>> may contain personal views which are not the views of the BBC unless specifically stated.
>>> If you have received it in
>>> error, please delete it from your system.
>>> Do not use, copy or disclose the
>>> information in any way nor act in reliance on it and notify the sender
>>> immediately.
>>> Please note that the BBC monitors e-mails
>>> sent or received.
>>> Further communication will signify your consent to
>>> this.
>>> -----------------------------
>> 
>> David Singer
>> Manager, Software Standards, Apple Inc.
>> 
>> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 23 September 2015 23:12:04 UTC