Re: TTML2/TTML1 Backwards compatibility analysis

On Wed, Oct 18, 2017 at 3:10 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Cyril,
>
> > I did not see the changes in TTML2 that would affect style inheritance.
> I may have missed it,
> > so if anyone could point to those differences, it'd be very useful.
>
> See https://github.com/w3c/ttml1/issues/220 .
>
> >  displayAspectRatio, but it is a new TTML2 feature, I'm assuming it was
> meant
> > to be pixelAspectRatio. Covered in my document. Have I missed anything?
>
> IMSC1 specifies ittp:aspectRatio [1]
>

which maps to ttp:displayAspectRatio in TTML2


>
> [1] https://www.w3.org/TR/ttml-imsc1/#ttp-aspectRatio
>
> Best,
>
> -- Pierre
>
> On Wed, Oct 18, 2017 at 1:57 PM, Cyril Concolato <cconcolato@netflix.com>
> wrote:
> > Thank you Mike for the feedback. See my comments inline.
> >
> > On Wed, Oct 18, 2017 at 8:52 AM, Michael Dolan <mike@dolan.tv> wrote:
> >>
> >> This is definitely a good exercise – thanks Cyril.  A few comments:
> >>
> >> The analysis is not clear about whether it covers documents, processors
> >> (in general) or presentation processors. The concern is about
> presentation
> >> processors, which is complicated by explicit potential for variations
> >> (available fonts, etc.). Some qualifications are needed of the form “all
> >> allowed variations being equal”;
> >
> > In this exercise I was concerned with how a TTML1 document (not
> containing
> > any TTML2 feature) would be rendered by a TTML2 presentation processor,
> in
> > particular if the rendering would be an acceptable results according to
> > TTML1. So this includes all variations allowed per TTML1.
> >
> >>
> >> Our editor came to a different conclusion (there are compatibility
> issues)
> >> with specific examples on a recent call, so we need to resolve that.
> Perhaps
> >> these are captured in the orange highlight (or should I say #FFA500 ;
> and
> >
> > From the 10/12 call, I can see:
> > - lineHeight. Covered in my document.
> > - displayAspectRatio, but it is a new TTML2 feature, I'm assuming it was
> > meant to be pixelAspectRatio. Covered in my document.
> > Have I missed anything?
> >
> > I'm concerned about:
> > - Pierre's words:
> > "basic things like lineHeight style inheritance."
> > I did not see the changes in TTML2 that would affect style inheritance. I
> > may have missed it, so if anyone could point to those differences, it'd
> be
> > very useful.
> >
> > - Glenn's words:
> > "There are layers that affect every feature - it's not simple than just
> > talking about
> > ... individual style features."
> > I'd like to understand what this means. I understand that there are
> general
> > aspects that affect every feature (like style resolution) or
> relationships
> > between style features (like DAR vs. PAR) but I didn't see "layers that
> > affect every feature" differently between TTML1 and TTML2.
> > Glenn, can you clarify? or give an example?
> >
> >
> >> Without consensus of an explicit stated goal of presentation processor
> >> backwards compatibility, it doesn’t mean it won’t break before
> publication
> >> as a Rec or be unintentionally vague; But we can’t seem to bring
> ourselves
> >> to make such a statement for some reason despite an agreement in
> principle 2
> >> meetings ago to do so (and my assignment to propose TTML2 spec
> language).
> >> But maybe this exercise will make everyone more comfortable doing that.
> >
> > Hopefully that should help the discussion stay focused and avoid
> discussing
> > for hours broad statements.
> >
> > Regards,
> > Cyril
> >>
> >>
> >>
> >> Regards,
> >>
> >>                Mike
> >>
> >>
> >>
> >> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
> >> Sent: Tuesday, October 17, 2017 10:00 AM
> >> To: Cyril Concolato <cconcolato@netflix.com>; public-tt@w3.org
> >> Subject: Re: TTML2/TTML1 Backwards compatibility analysis
> >>
> >>
> >>
> >> Thanks Cyril,
> >>
> >>
> >>
> >> I think it's very useful to focus on the concrete differences rather
> than
> >> the abstract – we may find that we can resolve them.
> >>
> >>
> >>
> >> I've added this (practical compatibility issues between TTML1 and TTML2)
> >> to Thursday's agenda.
> >>
> >>
> >>
> >> The URL in your email had an error in: the correct one should be
> >> https://docs.google.com/document/d/1Ri7RBBsbIK9SRxA1KsHRejXbYBuL4
> CRRrbmEZRbwZpg/edit?usp=sharing
> >>
> >>
> >>
> >> In the meantime if everyone interested in this could look at the
> document
> >> and comment/edit it etc that would be very helpful.
> >>
> >>
> >>
> >> Kind regards,
> >>
> >>
> >>
> >> Nigel
> >>
> >>
> >>
> >>
> >>
> >> From: Cyril Concolato <cconcolato@netflix.com>
> >> Date: Saturday, 14 October 2017 at 01:09
> >> To: "public-tt@w3.org" <public-tt@w3.org>
> >> Subject: TTML2/TTML1 Backwards compatibility analysis
> >> Resent-From: <public-tt@w3.org>
> >> Resent-Date: Saturday, 14 October 2017 at 01:11
> >>
> >>
> >>
> >> Hi all,
> >>
> >>
> >>
> >> Following yesterday's call, I started an analysis of the possible
> >> backwards compatibility issues of TTML2 vs TTML1. The results are here:
> >>
> >>
> >> https://docs.google.com/document/d/1Ri7RBBsbIK9SRxA1KsHRejXbYBuL4
> CRRrbmEZRbwZpg/edit?usp=sharing
> >>
> >>
> >>
> >> This is my analysis, and it might contain errors, oversights. If it is
> the
> >> case, feel free to comment on it.
> >>
> >>
> >>
> >> With the current status, it looks to me that there is no real backwards
> >> compatibility issue, in the sense that a TTML2 processor would produce a
> >> result, when processing a TTML1 document, that would be acceptable with
> what
> >> the TTML1 spec indicates.
> >>
> >>
> >>
> >> HTH,
> >>
> >> Cyril
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ----------------------------
> >>
> >> 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.
> >>
> >> ---------------------
> >
> >
>
>