Timed Text Working Group Teleconference

01 Jun 2017

See also: IRC log


Glenn, Andreas, Mike, Thierry
Dae, Pierre


<scribe> scribe: nigel

This Meeting

Nigel: For today, we have TTML stuff - issues, progress, TTML1 vs 2 compatibility, a little
... on IMSC that's in the agenda (even in Pierre's absence). Any thing specific to raise or AOB?

group: [silence]

Nigel: Okay then let's do it!

TTML issue assignment and progress tracking

Nigel: I just want to recognise the huge amount of work that Glenn has done on TTML2
... over the last month.

Glenn: I won't be able to make the telcos in June but will be able to work offline by
... email.

Nigel: So there's no point in proposing to move the meetings?

Glenn: No, I still wouldn't be able to attend.
... In terms of progress I have only 1 issue remaining for which there is no PR.
... The priority will be to wrap up the PRs and get to a version for WR. There may be
... some other issues that I will address too, some of them recent, like not deprecating
... ttp:profile. I don't know if I will be able to address the 24 or so issues raised by
... Richard Ishida, but if there are simple ones I will try to do that.
... For #195 on audio description I posted a preliminary PR which is not complete.
... I see there are comments on that from you Nigel which I will look at, so that's also
... on my list for June. I want to get all that work done by 23rd June which will give a
... week to prepare a final version of the WR and deal with any publishing issues.

Nigel: Our goal is to publish WR by end of June. Can we have a completed draft by
... 15th June to give 2 weeks review to verify that we have consensus?
... Any commits after then, unless they are addressing review comments, might not make it in.

Glenn: Ok I'll see how far I can get by the 15th.
... I'd like to talk today about the proposal for dealing with line gap, and the other
... is the lingering issues about em square and font size semantics.

Nigel: Ok, what about mediaOffset?

Glenn: The last issue I have, #96 on root temporal extent, encompasses that so I'm
... not yet ready to review that today - I'm still working on it.

Nigel: Ok

Glenn: That's a case where maybe we need a special call with interested parties to
... drill down into the details of that one.

Nigel: Sounds like a good idea.
... Status right now on TTML2:
... 44 open issues.
... 7 issues for group review or awaiting HR comment on disposition
... 28 open issues with no milestone
... (19 are horizontal review comments)
... 9 open on the Editor's WR work list.
... Glenn is there anything specific where it would be useful for input from others, e.g.
... editorial notes, examples?

Glenn: Not right now, #150 is the only one on here.
... I'd like to talk about today.

Nigel: Before we dive into the issues, are there any other changes anyone has begun
... to work on?

group: [silence]

TTML1 & TTML2 issues, actions, PRs, editorial actions etc

Revert deprecation of ttp:profile on root element. #331

Glenn: I posted a pull request on this last night that reverts the deprecation.

Nigel: There are two things to discuss here - the TTML1 vs TTML2 goal and the
... behaviour for ttp:profile if ttp:processorProfiles is also present.

Mike: I want a statement at the beginning of the document that states that all TTML1
... document instances shall be valid TTML2 documents. The handling of deprecations
... is delegated to the places where those deprecations are defined.

Glenn: I don't see a problem with stating that as an informative note.

Mike: That's what I have in mind.

Glenn: If you say "should validate" that's complex, maybe "should remain conformant"
... would be better. Validation may create warnings as well as errors. So a TTML2 based
... validation processor may emit warnings when processing a TTML1 document that
... uses something that's deprecated.

Mike: I had it right on the email - the important thing is to state informatively this
... goal at the beginning of the document, which should guide us on not obsoleting
... anything. I was concerned until I checked the meaning of "deprecate".
... I think we should use "conformant" language rather than "deprecate".

Glenn: Another interesting thing is the scenario of processing a TTML1 document
... under TTML2 rules rather than TTML1 rules. This could be done by a configuration
... parameter.

Mike: That would be good to mention - we're not changing the namespace are we?

Glenn: No we're not changing that.

Mike: It would be helpful to discriminate old from new documents.

Glenn: For example I could take a TTML1 document and add a v2 attribute to it. It is
... no longer strictly a TTML1 document because it has a version attribute. Now I feed
... that to a TTML2 processor

Nigel: So your point is that the processing of a TTML1 document under TTML2
... rules might generate different output from the same document processed under
... TTML1 rules?

Glenn: I just wanted to point out there are subtleties.

Andreas: I have a question about handling of TTML1 documents by a presentation
... processor. Is the presented result identical from a TTML2 processor as from a TTML1
... processor? Is that also guaranteed?

Glenn: I doubt if you get that with TTML1 processors.

Andreas: But I mean the intent.

Glenn: It's not true in general because you cannot guarantee what fonts are used, and
... the line breaking algorithm is not specified.

Andreas: My question is: is there any difference in TTML2 that would result in a
... different rendering from a TTML 1 processor, having taken out the non-deterministic parts?

Glenn: If the implementations have the same fonts, the same rasterisation processing
... and font implementation, and we assume that we are not considering implementatoin
... dependent differences. If you throw out all those variables then it probably should
... be close but I don't know if it would be exact even in theory. I don't think anything
... in TTML1 right now says the output of a presentation engine has to be identical.
... We don't have a testing regime to verify that.

Nigel: I'd flip this round and look for counter-examples. One of those is the handling
... of tts:origin and tts:extent on div and p elements. Presentation behaviour is not
... defined in TTML1 for that but it is in TTML2 so the two processing engines should
... generate different output given a document that uses that syntax.

Andreas: I think that example is interesting. I think if we add such a statement, we
... should add that all TTML1 documents should be processed okay by a TTML2
... processor, and that changes in TTML2 do not lead to different results than a TTML1
... processor. That is if we can be sure. Otherwise we should just state that document
... conformance is given for TTML1 documents as being valid TTML2 documents.

Glenn: In TTML1 we define 3 standard profiles - full, presentation and transformation.
... We tied those to v1 and in v2 that we are defining now we have created new
... profiles with the same names but slightly altered. Now instead of dfxp-full etc we
... have ttml2-full, ttml2-presentation and ttml2-transformation, so we have two sets
... of built-in profiles, one that applies to TTML1 and the other to TTML2. We are also
... extending the set of feature designators in TTML2. So a TTML2 processor can
... choose only to treat documents as TTML2 or to process TTML1 documents as
... faithfully to TTML1 as it can, except if ttp:version="2" which may lead to slightly
... different presentation potentially.

Nigel: In summary, we should not state that a TTML2 processor will generate the same
... output as a TTML1 processor for the same conformant TTML1 document, since we
... do not know in general that it is the case.

Glenn: I think we should put this note in the Conformance section.

Mike: Shall I file an issue?

Nigel: Yes please do it so we can track it.

Mike: On this issue, can I refer to it?

Glenn: We need to make sure that we deal with the "used value" of ttp:version.

Nigel: Are you happy for #331 to bring back the wording about precedence in case
... ttp:profile and ttp:processorProfiles are present?

Glenn: I thought there was some procedural wording there, I'll verify and if not then
... yes I'll put that wording back.

Mike: I think we should not permit both to be present in the same document instance.

Glenn: We do not prohibit content inside the TTML document.
... You may do that in a profile.

Mike: Why allow both in the same document?

Glenn: You should not but we cannot enforce author behaviour so we define what
... the processor does. It is clearly not violating a syntactic rule and we do not want to
... insist on a schema based rule to enforce it so we have semantic language that says
... you should not do both.

Mike: I think that's weird but I understand that's the common practice so I'll back off.

Glenn: This is the case for origin and position too, for example.

Nigel: I agree even if the authoring practice is not good we should have a defined
... behaviour rather than an undefined one.

Mike: Ok!

Glenn: I agree we need language to say you shouldn't do both and what to do if they
... are both present so I'll make sure that's there.

Mike: Thank you.

Glenn: I can handle the addition of a conformance note to #331.

Mike: I'll raise an issue about the obsoleted feature.

Line Gap

Ways to make span background height be lineHeight #150

Nigel: Glenn you requested here and on IMSC to make this a parameter attribute
... rather than a style attribute.
... We did discuss this for IMSC and concluded that it should be a style attribute.

Andreas: I tried to find this in the minutes from the London minutes, but as far as I
... recall we had this discussion and even then Glenn wanted just one attribute for the
... whole document; others had the strong view that it should be a style attribute.
... I cannot remember exactly the use case. I think we definitely discussed the solution
... and agreed to have it as a style attribute.

Nigel: +1

Glenn: I agree that's what we discussed.
... I'm not convinced at all that a single document instance would use more than one
... value at any point. I expect that documents would declare a style attribute as a top
... level inherited value or an initial value so they will have the same value everywhere.
... If we started out with a profile version we could add a style version later for
... more refinement.
... I think we don't have a requirement for it and it makes implementations and testing
... more complicated.

Nigel: Glenn you asked me for an example - I added one to the pull request

Issue 0150 inline background height #346

Nigel: This is based on the HbbTV 2.0.1 heuristic that does allow for documents to
... vary the line gap filling behaviour, so a single ttp: namespace attribute would not
... allow this example to work.

Andreas: We discussed this and decided the other way around. I think we should take
... it for granted that there is a requirement to apply it as a style to a paragraph, so it
... is not sufficient to have a document wide setting.

Nigel: +1

Change itts:fillLineGap to ittp:fillLineGap. #238

Glenn: Since it is a style attribute in IMSC 1.0.1 I will close the issue and go back to
... a style attribute - I don't particularly like it!
... Are you happy if I make the change to #346 that I can merge it.

Nigel: Please could you make the change and then allow us time to double check it?

Glenn: Ok. By the way the reason I ended up going this way is because earlier on I had
... proposed special values in bpd, but the more I tried that the more conflicts I uncovered
... so doing something special is warranted. bpd and ipd do not apply to inline areas
... that are not inline blocks so coming up with special language was too strange and
... complicated to manage.

#200 Two value percentage font sizes

Two value percentage fontSize not fully defined #200

Nigel: I'm concerned that we are removing the semantic that allows the author to
... define only the font height and have the processor present the glyphs without
... any anamorphic scaling, possibly with knowledge of the display aspect ratio.

Glenn: It is already the case that font size has a defined width and height for the em
... square. Logical pixels do not have any aspect ratio and we are talking about logical
... pixel space here. When we scale the em square to a logical width and height...

[discussion of issue - scribe thinking not typing!]

Nigel: [Presents starting condition of no tts:extent on root, use of %age dimensions,
... implementation chooses what SAR, DAR etc to calculate.]

Glenn: [walks through this]
... e.g. for a 4:3 display the implementation would choose a SAR of e.g. 640x480.
... That's up to the implementation to decide. Now we have SAR=DAR and PAR=1.
... In this case all logical pixels map to square display pixels so if you specify a fontSize
... of say "10%" on the region then you get logical pixels 64 high and 64 wide. Since
... here we are mapping those to square display pixels you end up with a square em
... square.

Nigel: Okay I think you might have persuaded me - if you switched to a 16:9 display
... you would get more horizontal pixels and they would still be square.
... By the way the issue originally arose because, although in the case we just went
... through, the SAR is known, in a transformation processor it can not always be
... known. There is one trick we could play which is to consider the horizontal width
... as an equivalent rh value (i.e. width is a proportion of the height).

Glenn: That's in the PR.

Nigel: That's PR #336, which is merged.

Glenn: There's a note example under fontSize.

Nigel: Is it clear which pixels we mean, now that we define two kinds in Annex H.

Glenn: I have a note to myself to explain that we mean logical pixels. I think there may
... be one place that you [Nigel] pointed out recently where we say display pixels but
... we mean logical pixels.
... Presentation Context Coordinate Space - under tts:position there's an image about
... percentage based positioning and a couple of paragraphs down it mentions it.
... So I need to review that and make sure that is is correct.
... I've noted for myself that all layout is done in logical pixels.

Nigel: I think that's worth clarifying.

Meeting close

Nigel: We're out of time, thank you everyone. For those who are going to be present,
... see you next week. Final word: please do review TTML2 now and raise any issues
... sooner rather than later - anyone raising a bunch of issues on June 28 is just going
... to create upset! [adjourns meeting]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/06/01 16:19:04 $