IRC log of tt on 2017-06-01

Timestamps are in UTC.

14:04:31 [RRSAgent]
RRSAgent has joined #tt
14:04:31 [RRSAgent]
logging to
14:04:33 [trackbot]
RRSAgent, make logs public
14:04:33 [Zakim]
Zakim has joined #tt
14:04:35 [trackbot]
Zakim, this will be TTML
14:04:35 [Zakim]
ok, trackbot
14:04:36 [trackbot]
Meeting: Timed Text Working Group Teleconference
14:04:36 [trackbot]
Date: 01 June 2017
14:05:07 [nigel]
scribe: nigel
14:06:31 [nigel]
Present: Glenn, Andreas, Mike
14:06:36 [nigel]
Regrets: Dae, Pierre
14:07:07 [nigel]
Present+ Thierry
14:07:12 [nigel]
Chair: Nigel
14:08:04 [nigel]
Topic: This Meeting
14:08:55 [nigel]
Nigel: For today, we have TTML stuff - issues, progress, TTML1 vs 2 compatibility, a little
14:09:47 [nigel]
.. on IMSC that's in the agenda (even in Pierre's absence). Any thing specific to raise or AOB?
14:10:10 [nigel]
group: [silence]
14:10:15 [nigel]
Nigel: Okay then let's do it!
14:10:41 [atai]
atai has joined #tt
14:11:12 [nigel]
Topic: TTML issue assignment and progress tracking
14:11:37 [nigel]
Nigel: I just want to recognise the huge amount of work that Glenn has done on TTML2
14:11:44 [nigel]
.. over the last month.
14:13:16 [nigel]
Glenn: I won't be able to make the telcos in June but will be able to work offline by
14:13:20 [nigel]
.. email.
14:13:31 [nigel]
Nigel: So there's no point in proposing to move the meetings?
14:13:37 [nigel]
Glenn: No, I still wouldn't be able to attend.
14:13:53 [nigel]
Glenn: In terms of progress I have only 1 issue remaining for which there is no PR.
14:14:14 [nigel]
.. The priority will be to wrap up the PRs and get to a version for WR. There may be
14:14:25 [nigel]
.. some other issues that I will address too, some of them recent, like not deprecating
14:14:40 [nigel]
.. ttp:profile. I don't know if I will be able to address the 24 or so issues raised by
14:14:54 [nigel]
.. Richard Ishida, but if there are simple ones I will try to do that.
14:15:08 [nigel]
.. For issue 195 on audio description I posted a preliminary PR which is not complete.
14:15:29 [nigel]
.. I see there are comments on that from you Nigel which I will look at, so that's also
14:15:42 [nigel]
.. on my list for June. I want to get all that work done by 23rd June which will give a
14:15:54 [nigel]
.. week to prepare a final version of the WR and deal with any publishing issues.
14:17:16 [nigel]
Nigel: Our goal is to publish WR by end of June. Can we have a completed draft by
14:17:43 [nigel]
.. 15th June for review to give 2 weeks review to verify that we have consensus?
14:18:14 [nigel]
.. Any commits after then, unless they are addressing review comments, might not make it in.
14:18:22 [nigel]
Glenn: Ok I'll see how far I can get by the 15th.
14:22:30 [nigel]
Glenn: I'd like to talk today about the proposal for dealing with line gap, and the other
14:22:38 [nigel]
.. is the lingering issues about em square and font size semantics.
14:22:50 [nigel]
Nigel: Ok, what about mediaOffset?
14:23:08 [nigel]
Glenn: The last issue I have, #96 on root temporal extent, encompasses that so I'm
14:23:18 [nigel]
.. not yet ready to review that today - I'm still working on it.
14:23:33 [nigel]
Nigel: Ok
14:23:45 [nigel]
Glenn: That's a case where maybe we need a special call with interested parties to
14:23:51 [nigel]
.. drill down into the details of that one.
14:24:54 [nigel]
Nigel: Sounds like a good idea.
14:24:59 [nigel]
.. Status right now on TTML2:
14:25:04 [nigel]
.. 44 open issues.
14:25:25 [nigel]
.. 7 issues for group review or awaiting HR comment on disposition
14:25:37 [nigel]
.. 28 open issues with no milestone
14:26:04 [nigel]
.. (19 are horizontal review comments)
14:26:40 [nigel]
.. 9 open on the Editor's WR work list.
14:27:21 [nigel]
.. Glenn is there anything specific where it would be useful for input from others, e.g.
14:27:28 [nigel]
.. editorial notes, examples?
14:27:36 [nigel]
Glenn: Not right now, #150 is the only one on here.
14:27:53 [nigel]
.. I'd like to talk about today.
14:28:21 [nigel]
Nigel: Before we dive into the issues, are there any other changes anyone has begun
14:28:24 [nigel]
.. to work on?
14:28:29 [nigel]
group: [silence]
14:29:02 [nigel]
Topic: TTML1 & TTML2 issues, actions, PRs, editorial actions etc
14:29:25 [nigel]
-> Revert deprecation of ttp:profile on root element. #331
14:29:36 [nigel]
Glenn: I posted a pull request on this last night that reverts the deprecation.
14:31:26 [nigel]
Nigel: There are two things to discuss here - the TTML1 vs TTML2 goal and the
14:33:18 [nigel]
.. behaviour for ttp:profile if ttp:processorProfiles is also present.
14:33:31 [nigel]
Mike: I want a statement at the beginning of the document that states that all TTML1
14:33:50 [nigel]
.. document instances shall be valid TTML2 documents. The handling of deprecations
14:33:58 [nigel]
.. is delegated to the places where those deprecations are defined.
14:34:10 [nigel]
Glenn: I don't see a problem with stating that as an informative note.
14:34:17 [nigel]
Mike: That's what I have in mind.
14:34:30 [nigel]
Glenn: If you say "should validate" that's complex, maybe "should remain conformant"
14:34:43 [nigel]
.. would be better. Validation may create warnings as well as errors. So a TTML2 based
14:34:55 [nigel]
.. validation processor may emit warnings when processing a TTML1 document that
14:35:07 [nigel]
.. uses something that's deprecated.
14:35:17 [nigel]
Mike: I had it right on the email - the important thing is to state informatively this
14:35:29 [nigel]
.. goal at the beginning of the document, which should guide us on not obsoleting
14:35:46 [nigel]
.. anything. I was concerned because I needed to check the meaning of "deprecate".
14:36:01 [nigel]
.. I think we should use "conformant" language rather than "deprecate".
14:36:21 [nigel]
Glenn: Another interesting thing is the scenario of processing a TTML1 document
14:36:45 [nigel]
.. under TTML2 rules rather than TTML1 rules. This could be done by a configuration
14:36:51 [nigel]
.. parameter.
14:37:03 [nigel]
Mike: That would be good to mention - we're not changing the namespace are we?
14:37:10 [nigel]
Glenn: No we're not changing that.
14:37:21 [nigel]
Mike: It would be helpful to discriminate old from new documents.
14:37:34 [nigel]
Glenn: For example I could take a TTML1 document and add a v2 attribute to it. It is
14:37:52 [nigel]
.. no longer strictly a TTML1 document because it has a version attribute. Now I feed
14:38:20 [nigel]
.. that to a TTML2 processor
14:38:36 [nigel]
Nigel: So your point is that the processing of a TTML1 document under TTML2
14:38:48 [nigel]
.. rules might generate different output from the same document processed under
14:38:53 [nigel]
.. TTML1 rules?
14:39:00 [nigel]
Glenn: I just wanted to point out there are subtleties.
14:40:30 [nigel]
Andreas: I have a question about handling of TTML1 documents by a presentation
14:40:41 [nigel]
.. processor. Is the presented result identical from a TTML2 processor as from a TTML1
14:40:49 [nigel]
.. processor? Is that also guaranteed?
14:40:58 [nigel]
Glenn: I doubt if you get that with TTML1 processors.
14:41:06 [nigel]
Andreas: But I mean the intent.
14:41:21 [nigel]
Glenn: It's not true in general because you cannot guarantee what fonts are used, and
14:41:29 [nigel]
.. the line breaking algorithm is not specified.
14:41:44 [nigel]
Andreas: My question is: is there any difference in TTML2 that would result in a
14:42:04 [nigel]
.. different rendering from a TTML 1 processor, having taken out the non-deterministic parts.
14:42:20 [nigel]
Glenn: If the implementations have the same fonts, the same rasterisation processing
14:42:35 [nigel]
.. and font implementation, and we assume that we are not considering implementatoin
14:42:58 [nigel]
.. dependent differences. If you throw out all those variables then it probably should
14:43:11 [nigel]
.. be close but I don't know if it would be exact even in theory. I don't think anything
14:43:23 [nigel]
.. in TTML1 right now says the output of a presentation engine has to be identical.
14:43:31 [nigel]
.. We don't have a testing regime to verify that.
14:45:46 [nigel]
Nigel: I'd flip this round and look for counter-examples. One of those is the handling
14:45:59 [nigel]
.. of tts:origin and tts:extent on div and p elements. Presentation behaviour is not
14:46:12 [nigel]
.. defined in TTML1 for that but it is in TTML2 so the two processing engines should
14:46:23 [nigel]
.. generate different output given a document that uses that syntax.
14:46:42 [nigel]
Andreas: I think that example is interesting. I think if we add such a statement, we
14:46:59 [nigel]
.. should add that all TTML1 documents should be processed okay by a TTML2
14:47:18 [nigel]
.. processor, and that changes in TTML2 do not lead to different results than a TTML1
14:47:33 [nigel]
.. processor. That is if we can be sure. Otherwise we should just state that document
14:47:43 [nigel]
.. conformance is given for TTML1 documents as being valid TTML2 documents.
14:48:08 [nigel]
Glenn: In TTML1 we define 3 standard profiles - full, presentation and transformation.
14:48:23 [nigel]
.. We tied those to v1 and in v2 that we are defining now we have created new
14:48:37 [nigel]
.. profiles with the same names but slightly altered. Now instead of dfxp-full etc we
14:48:50 [nigel]
.. have ttml2-full, ttml2-presentation and ttml2-transformation, so we have two sets
14:49:02 [nigel]
.. of built-in profiles, one that applies to TTML1 and the other to TTML2. We are also
14:49:20 [nigel]
.. extending the set of feature designators in TTML2. So a TTML2 processor can
14:49:36 [nigel]
.. choose only to treat documents as TTML2 or to process TTML1 documents as
14:49:58 [nigel]
.. faithfully to TTML1 as I can, except if ttp:version="2" which may lead to slightly
14:50:02 [nigel]
.. different presentation potentially.
14:50:49 [nigel]
Nigel: In summary, we should not state that a TTML2 processor will generate the same
14:51:09 [nigel]
.. output as a TTML1 processor for the same conformant TTML1 document, since we
14:51:17 [nigel]
.. do not know in general that it is the case.
14:51:26 [nigel]
Glenn: I think we should put this note in the Conformance section.
14:51:34 [nigel]
Mike: Shall I file an issue?
14:51:48 [nigel]
Nigel: Yes please do it so we can track it.
14:52:36 [nigel]
Mike: On this issue, can I refer to it?
14:52:55 [nigel]
Glenn: We need to make sure that we deal with the "used value" of ttp:version.
14:54:28 [nigel]
Nigel: Are you happy for #331 to bring back the wording about precedence in case
14:54:38 [nigel]
.. ttp:profile and ttp:processorProfiles are present?
14:54:52 [nigel]
Glenn: I thought there was some procedural wording there, I'll verify and if not then
14:54:56 [nigel]
.. yes I'll put that wording back.
14:55:08 [nigel]
Mike: I think we should not permit both to be present in the same document instance.
14:55:19 [nigel]
Glenn: We do not prohibit content inside the TTML document.
14:55:25 [nigel]
.. You may do that in a profile.
14:55:35 [nigel]
Mike: Why allow both in the same document?
14:55:47 [nigel]
Glenn: You should not but we cannot enforce author behaviour so we define what
14:56:01 [nigel]
.. the processor does. It is clearly not violating a syntactic rule and we do not want to
14:56:14 [nigel]
.. insist on a schema based rule to enforce it so we have semantic language that says
14:56:19 [nigel]
.. you should not do both.
14:56:39 [nigel]
Mike: I think that's weird but I understand that's the common practice so I'll back off.
14:56:52 [nigel]
Glenn: This is the case for origin and position too, for example.
14:57:25 [nigel]
Nigel: I agree even if the authoring practice is not good we should have a defined
14:57:32 [nigel]
.. behaviour rather than an undefined one.
14:57:38 [nigel]
Mike: Ok!
14:58:05 [nigel]
Glenn: I agree we need language to say you shouldn't do both and what to do if they
14:58:16 [nigel]
.. are both present so I'll make sure that's there.
14:58:20 [nigel]
Mike: Thank you.
14:59:27 [nigel]
Glenn: I can handle the addition of a conformance note to #331.
14:59:46 [nigel]
Mike: I'll raise an issue about the obsoleted feature.
15:02:20 [nigel]
rrsagent, make minutes
15:02:20 [RRSAgent]
I have made the request to generate nigel
15:07:29 [nigel]
Topic: Line Gap
15:08:17 [nigel]
-> Ways to make span background height be lineHeight #150
15:08:52 [nigel]
Nigel: Glenn you requested here and on IMSC to make this a parameter attribute
15:08:56 [nigel]
.. rather than a style attribute.
15:09:16 [atai]
15:09:36 [nigel]
Nigel: We did discuss this for IMSC and concluded that it should be a style attribute.
15:09:40 [nigel]
ack atai
15:09:51 [nigel]
Andreas: I tried to find this in the minutes from the London minutes, but as far as I
15:10:09 [nigel]
.. recall we had this discussion and even then Glenn wanted just one attribute for the
15:10:30 [nigel]
.. whole document; others had the strong view that it should be a style attribute.
15:10:40 [nigel]
.. I cannot remember exactly the use case. I think we definitely discussed the solution
15:10:47 [nigel]
.. and agreed to have it as a style attribute.
15:10:50 [nigel]
Nigel: +1
15:11:01 [nigel]
Glenn: I agree that's what we discussed.
15:11:10 [nigel]
.. I'm not convinced at all that a single document instance would use more than one
15:11:32 [nigel]
.. value at any point. I expect that documents would declare a style attribute as a top
15:11:44 [nigel]
.. level inherited value or an initial value so they will have the same value everywhere.
15:11:59 [nigel]
.. If we started out with a parameter version we could add a style version later for
15:12:03 [nigel]
.. more refinement.
15:12:14 [nigel]
15:12:24 [nigel]
.. I think we don't have a requirement for it and it makes implementations and testing
15:12:26 [nigel]
.. more complicated.
15:13:58 [nigel]
Nigel: Glenn you asked me for an example - I added one to the pull request
15:14:10 [nigel]
-> 0150 inline background height #346
15:17:04 [nigel]
Nigel: This is based on the HbbTV 2.0.1 heuristic that does allow for documents to
15:17:22 [nigel]
.. vary the line gap filling behaviour, so a single ttp: namespace attribute would not
15:17:26 [nigel]
.. allow this example to work.
15:17:39 [nigel]
Andreas: We discussed this and decided the other way around. I think we should take
15:17:59 [nigel]
.. it for granted that there is a requirement to apply it as a style to a paragraph, so it
15:18:07 [nigel]
.. is not sufficient to have a document wide setting.
15:18:10 [nigel]
Nigel: +1
15:20:11 [nigel]
-> Change itts:fillLineGap to ittp:fillLineGap. #238
15:22:56 [nigel]
Glenn: Since it is a style attribute in IMSC 1.0.1 I will close the issue and go back to
15:23:10 [nigel]
.. a style attribute - I don't particularly like it!
15:23:27 [nigel]
s|346Issue|346 Issue
15:24:07 [nigel]
Glenn: Are you happy if I make the change to #346 that I can merge it.
15:24:16 [nigel]
Nigel: Please could you make the change and then allow us time to double check it?
15:24:31 [nigel]
Glenn: Ok. By the way the reason I ended up going this way is because earlier on I had
15:24:46 [nigel]
.. proposed special values in bpd, but the more I tried that the more conflicts I uncovered
15:24:59 [nigel]
.. so doing something special is warranted. bpd and ipd do not apply to inline areas
15:25:17 [nigel]
.. that are not inline blocks so coming up with special language was too strange and
15:25:24 [nigel]
.. complicated to manage.
15:26:38 [nigel]
Topic: #200 Two value percentage font sizes
15:26:44 [nigel]
-> Two value percentage fontSize not fully defined #200
15:28:01 [nigel]
Nigel: I'm concerned that we are removing the semantic that allows the author to
15:28:15 [nigel]
.. define only the font height and have the processor present the glyphs without
15:28:27 [nigel]
.. any anamorphic scaling, possibly with knowledge of the display aspect ratio.
15:28:55 [nigel]
Glenn: It is already the case that font size has a defined width and height for the em
15:29:53 [nigel]
.. square. Logical pixels do not have any aspect ratio and we are talking about logical
15:38:27 [nigel]
.. pixel space here. When we scale the em square to a logical width and height...
15:38:56 [nigel]
[discussion of issue - scribe thinking not typing!]
15:40:38 [nigel]
Nigel: Presents starting condition of no tts:extent on root, use of %age dimensions,
15:41:27 [nigel]
.. implementation chooses what SAR, DAR etc to calculate.
15:41:39 [nigel]
Glenn: [walks through this]
15:42:30 [nigel]
.. e.g. for a 4:3 display the implementation would choose a SAR of e.g. 640x480.
15:42:42 [nigel]
.. That's up to the implementation to decide. Now we have SAR=DAR and PAR=1.
15:43:10 [nigel]
.. In this case all logical pixels map to square display pixels so if you specify a fontSize
15:43:37 [nigel]
.. of say "10%" on the region then you get logical pixels 64 high and 64 wide. Since
15:43:49 [nigel]
.. here we are mapping those to square display pixels you end up with a square em
15:45:23 [nigel]
.. square.
15:46:07 [nigel]
Nigel: Okay I think you might have persuaded me - if you switched to a 16:9 display
15:46:17 [nigel]
.. you would get more horizontal pixels and they would still be square.
15:47:20 [nigel]
.. By the way the issue originally arose because, although in the case we just went
15:47:34 [nigel]
.. through, the SAR is known, in a transformation processor it can not always be
15:48:58 [nigel]
.. known. There is one trick we could play which is to consider the horizontal width
15:49:12 [nigel]
.. as an equivalent rh value (i.e. width is a proportion of the height).
15:49:47 [nigel]
Glenn: That's in the PR.
15:49:53 [nigel]
Nigel: That's PR #336, which is merged.
15:52:45 [nigel]
Glenn: There's a note example under fontSize.
15:52:57 [nigel]
Nigel: Is it clear which pixels we mean, now that we define two kinds in Annex H.
15:53:24 [nigel]
Glenn: I have a note to myself to explain that we mean logical pixels. I think there may
15:53:41 [nigel]
.. be one place that you [Nigel] pointed out recently where we say display pixels but
15:53:46 [nigel]
.. we mean logical pixels.
15:54:01 [nigel]
.. Presentation Context Coordinate Space - under tts:position there's an image about
15:54:14 [nigel]
.. percentage based positioning and a couple of paragraphs down it mentions it.
15:54:22 [nigel]
.. So I need to review that and make sure that is is correct.
15:56:17 [nigel]
Glenn: I've noted for myself that all layout is done in logical pixels.
15:56:23 [nigel]
Nigel: I think that's worth clarifying.
15:58:26 [atai]
15:59:51 [nigel]
ack atai
16:02:08 [atai]
atai has left #tt
16:02:14 [nigel]
Topic: Meeting close
16:02:32 [nigel]
Nigel: We're out of time, thank you everyone. For those who are going to be present,
16:03:05 [nigel]
.. see you next week. Final word: please do review TTML2 now and raise any issues
16:03:18 [nigel]
.. sooner rather than later - anyone raising a bunch of issues on June 28 is just going
16:03:29 [nigel]
.. to create upset! [adjourns meeting]
16:03:36 [nigel]
rrsagent, make minutes
16:03:36 [RRSAgent]
I have made the request to generate nigel
16:09:04 [nigel]
s/issue 195/#195
16:09:29 [nigel]
s/15th June for review/15th June
16:10:48 [nigel]
s/because I needed to check/until I checked
16:11:30 [nigel]
s/non-deterministic parts./non-deterministic parts?
16:12:34 [nigel]
s/faithfully to TTML1 as I can/faithfully to TTML1 as it can
16:14:46 [nigel]
s/Presents starting condition/[Presents starting condition
16:14:55 [nigel]
s/DAR etc to calculate./DAR etc to calculate.]
16:15:56 [nigel]
rrsagent, make minutes
16:15:56 [RRSAgent]
I have made the request to generate nigel
16:18:28 [nigel]
ScribeOptions: -final -noEmbedDiagnostics
16:18:29 [nigel]
rrsagent, make minutes
16:18:29 [RRSAgent]
I have made the request to generate nigel