Timed Text Working Group Teleconference

15 Jun 2017

See also: IRC log


Nigel, Mike, Pierre, Thierry, Dae
Andreas, Glenn


<scribe> scribe: nigel

This meeting

Nigel: Today we need to move forward with IMSC and TTML. I will briefly mention TPAC. Any specific points to cover, or other business?

Mike: The IMSC 1 issue regarding SDP-US

TPAC 2017

Nigel: I've had confirmation from the newly re-chartered Media and Entertainment IG (was Web and TV)
... that we can meet them jointly for 30 minutes on the Monday.
... I proposed a draft agenda of an update on subtitle and caption work including TTML2, IMSC 1.0.1, industry adoption
... Seek input on IMSC 2 requirements
... Gauge interest in a possible profile of TTML2 for AD
... plus any other topics of interest.
... I suggested afternoon would be better than morning in case there's any last minute preparation to done.


<trackbot> action-497 -- Nigel Megitt to Invite csswg to joint meeting at tpac 2017, with list of topics. -- due 2017-06-15 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/497

Nigel: I haven't progressed this yet.
... I will gather together the details as discussed last week and hopefully progress that in the next week.
... Registration is now open, as are the preferred rates for hotels - early booking is recommended.



<trackbot> action-498 -- Nigel Megitt to Invite i18n to discuss imsc 1.0.1 issues -- due 2017-06-15 -- PENDINGREVIEW

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/498

Nigel: I did invite Richard and Addison but they have not either joined or said they would be (un)able to do so.
... However there has been some discussion offline.

Pierre: I suggested it would be easier to have the discussion live but we can go ahead and try to propose a solution and disposition
... and deal with the response.
... I'm fairly confident that the root of the issues is mainly a misunderstanding of the specification.

Nigel: Some of the github issues have been discussed offline.

Pierre: By the way I'm not blaming anyone, but conflating reference fonts with recommended character sets is a problem.
... They are really separate. I hope I clarified some of that. Specifically the idea of recommended sets is for author to have confidence
... that characters for a particular language will be displayed and for implementers to have confidence that they are supporting the
... correct code points. Separately and independently there are a set of reference fonts that are specified, but the choice of recommended character
... sets was made independently of the reference fonts. And the "rendering fidelity" associated with recommended character sets is whether they
... display at all, period, whereas for reference fonts it is about metrics, line breaking positions etc. So I think this is where the misunderstanding lies.
... So in a pull request I tried to clarify it. At some point we have to propose something and let them restart the discussion if they feel the issue is not
... resolved.

Mike: I'm sympathetic - this is a complicated topic, but I also believe the spec is clear. I think we have done what we can.

Clarified the requirement for processors to implement reference fonts #245

Nigel: This is for #237 and #241.

Pierre: It has also been discussed in relation to #236.

Nigel: From the discussion are there more changes you want to apply to resolve the misunderstandings?

Pierre: Maybe less not more!
... The note "Since the flow of text..." is the one we maybe need to work on.

Nigel: Did you see my proposed alternate wording?


Pierre: I'm fine with it - I hope people won't read too much into it.
... It's not only the flow of text but also the background, the effective size of the subtitle.

Mike: Yes, line height, characters per line.

Pierre: Gaps between lines.

Mike: It's sweeping so having the reference font is critical.
... From a web browser perspective some of this must seem strange, but for this application the web approach doesn't really work.
... I don't know how you say that in a note!

Nigel: So "flow of text" is too generic?

Pierre: Or not broad enough. It is the whole appearance of the subtitle - I think that's a true statement. We could try to list it all but
... evidently it is not obvious.

Nigel: The other thing we maybe need to clarify is the scenarios where reference fonts apply - it maybe does not jump out
... enough that reference fonts only come into play for a very specific subset of computed values of tts:fontFamily.

Pierre: That's extremely explicit though. Without Richard on the call I think we're grasping at straws.
... In light of what we just talk about what should we do? Have a more generic note about the appearance of the subtitle?

Nigel: Yes, if you want to try to craft that I'd be happy to review it.

Pierre: I'll do it now and we can review it later.
... My recommendation is to apply the pull request and propose it as a disposition and get the response.

Nigel: I think that's fair. Any other views?

Mike: No.

Attribute syntax definition: missing spaces #221

Pierre: Option 2 was preferred and there was no reaction against it, so I've drafted a pull request on that basis assuming that TTML1 will
... clarify that spaces are in fact permitted, and rejiggered IMSC to take that into account.

Required spaces between non-terminal components of styling and parameter attributes (issue #221) #230

Pierre: This PR puts references into TTML1 for the sections on attribute syntax, and IMSC assumes it is permitted and says "you should not do that" (in document instances).

Nigel: I see you've specified no white space between digit tokens... That's not to say you can't distinguish numerator from denominator!

Pierre: No just between digits. If you look say at %age in TTML1 it is clear that no LWSP is permitted between them.
... It is obvious to me, but it was obvious that there would be no spaces between fontFamily components, so I'd rather err on the side of completeness.

Nigel: +1
... Do you want to merge that then?

Pierre: Yes

Nigel: okay, nobody has any objections, go ahead.

Pierre: Done.

Nigel: We have one more, which is #242:

-> https://github.com/w3c/imsc/pull/242 Discourage the use of tab characters in <p> and <span> #242

Pierre: That's one day away from the 14 days and there have been no comments.

Nigel: I've just approved it by review.
... When it comes to Dispositions the main one we need to address is ARIB since all the other comments are W3 internal.

IMSC 1.0.1 comments tracker wiki page

Nigel: Thierry the ARIB liaison has listed on that wiki page that it is under review and not edited in the spec.

Thierry: That was the status about a week ago.

Nigel: I'm puzzled I thought it had been done.

Pierre: Yes, they are #227 and #228 and they have been merged and are ready for review.
... The proposed email states that.
... You said that you and Thierry would review and send it after this meeting.

Nigel: The last email in the thread is:


Nigel: OK I see. Does anyone have any comments or changes on the proposed response and dispositions?

group: [silence]

Nigel: In that case let us take that as approval!

Thierry: OK I will send that.

Nigel: Thank you.

Thierry: Just one thing - is 1 week response time enough?

Nigel: I think 1 week is very short.

Pierre: Do we have to get a response? Or can we proceed with no response after some time?

Thierry: The best is a response, but if not then we can go ahead to the Director in any case.

Pierre: Can we work backwards from when we want to publish the CR?

Nigel: I don't want to have our TTML2 and IMSC 1.0.1 publications clash.

Thierry: Only one is a transition - the other is just another WD.

Pierre: How about transitioning on July 6? Mid-July would not work for me.

Thierry: We can go straight to PR if we have implementation experience already. I've seen that before.

Nigel: I thought the Process sets a minimum duration for CR? But if not, then okay fine.
... I believe we have one implementation of fillLineGap already, and implementing activeArea is trivial.

Thierry: I'll check the process.

Nigel: [also checks] - the 4 week minimum appears to be for getting comments on the way into CR not on the way out.
... In that case when are other implementations expected?
... I'm happy either way - we can go straight to PR otherwise CR.

Pierre: We can review that on July 6.

Nigel: July 6 is 3 weeks out, so we could offer 2 weeks.

Pierre: Then we could plan on transitioning on June 30.

Nigel: Accepting TTML2 is a WD only, it is much bigger so I would rather not schedule 2 document publications on the same day - I would rather wait until
... July 6 for IMSC.
... If we say that then we need a resolution to publish IMSC 1.0.1 as a CR (or PR) no later than next week's meeting.
... That gives us this coming week to mop up any remaining open issues.
... Thierry can we say 2 weeks for the disposition response?

Thierry: Yes

Pierre: I would say explicitly the date we plan to transition.

Thierry: We need to have the response before meeting the Director.

Pierre: Okay then 2 weeks for sure. I would be explicit about the planned transition dates too.

Nigel: I'm happy with the 2 weeks but I don't agree that we should include more dates of planned transitions etc - just say when we need the response back.

Pierre: Okay I'm fine with that too.

SDP-US is listed as a normative reference, but it is not #246

Mike: This was prompted by a discussion with someone who thought that SDP-US is critical to implementation of IMSC1. However
... implementation of SDP-US is not critical at all, so the normative reference is an error.

Pierre: Does a normative reference imply complete implementation of the referenced document or just the relevant bits?

Mike: The latter.

Pierre: That's my understanding too. The current text says "if the document conforms to SDP-US you shouldn't use ttp:profile".

Mike: That's poor choice of words and not IMSC1's business.
... Conformance with SDP-US is not IMSC1's business. If you want an SDP-US document do that. This is just a declarative note.

Pierre: So you're arguing that's a statement not a conformance clause?

Mike: Yes absolutely. If you want to go there (and I don't), it's a declarative note only. It is not a conformance term for IMSC 1 and has nothing to do with
... IMSC 1 conformance.

Pierre: My thinking is: as currently written it is evidently misleading, but not wrong. If we are going to move the normative reference to an informative one then
... we should change this clause and remove any conformance.

Mike: I don't think we should wander into conformance here.

Nigel: There is also Annex I about compatibility with other TTML-based specifications.
... Effectively the same wording is duplicated there.
... And that's a useful service given the design goal to be a superset.

Pierre: Looking at §6.9 Profile Signaling...
... SDP-US prohibits the ttp:profile attribute from being present.
... In order for me to evaluate the clause in §6.9 I need to go and read SDP-US.

Mike: And it shouldn't make me do that.

Pierre: That's the root cause of this. You're suggesting that we should change the wording to be informative and move the reference to the non-normative section?

Mike: Yes, I'd like to refactor this to remove the normative reference.
... The ramifications are editorial: the use of SHOULD originally was a bad choice.

Pierre: Section I.3 has the declarative statement.

Nigel: Just checking all the other references to SDP-US, they all seem to be declarative.

Pierre: We could reword §6.9 to match §I.3.

Mike: Why do we need to repeat it?

Pierre: Because it is important to clarify the profile signalling from TTML1.

Mike: I'm okay either a) deleting the sentence or b) restating it as a declarative statement.
... There are a number of ways to remove this from the normative references.

Nigel: I don't have any objection to removing it from normative references. By the way it is only a WG Note, so it's a bit odd for us to normatively
... reference it anyhow, I'm not sure how that slipped by.

Pierre: It could be just a missing ! - I can prepare a pull request.

Mike: I do believe this was just a mistake.

Pierre: I believe we will have to list this as a substantive change even though it has no conformance impact.

Nigel: I agree.

Pierre: I will prepare a pull request later today, if you could review it and let me know if there are any issues.

Mike: Thanks guys.

Pierre: Shall we go back to #245 which I have now updated?

Nigel: Given the time let's do that offline please.
... Summarising for the minutes, we have done what we can on the i18n issues, agreed the disposition response and made a plan
... to make the resolution to transition to CR or possibly even PR in next week's meeting for a July 6 publication target.


Nigel: We said we would publish the WD for wide review by June 30, and that we would need a 2 week review period to approve it.
... We have a number of open pull requests now and no final draft of the WD to review.
... We also a number of open issues.
... I wanted to propose that we merge all the current open pull requests and turn that into a draft that the group can
... review prior to approving publication for wide review. That gives a 2 week review period for everyone. How does that grab everyone?

Mike: Okay for me.

Nigel: Clearly we can still make further changes prior to CR, or resolve issues with this version by pull requests in the next few days as long as there is
... positive review from enough key people, and no negative comments.

Dae: I'm more interested in the deadline than having 2 full weeks. 1 week review is enough for me.

Pierre: Movielabs will abstain on this at this time.

Thierry: The proposal sounds reasonable to me.

Nigel: OK then I think we're agreed.
... I will ask Glenn to progress that.
... Let's go through the pull requests then.

Issue 0384 streaming ttml appendix #389

HTML version

Nigel: It's appendix R
... I didn't quite do what we said last week in that I didn't reference the TTML1 appendix but left it in as a subsection.
... I did that on the basis of one of Glenn's comments on the issue.

Mike: I would rather do what we said last week and diminish the relevance of the section that isn't common practice by making it a reference back to TTML1.

Nigel: I have limited time available in the short term to fix this so unless there are strong objections to what we have I propose to keep it as is,
... or otherwise I'd welcome if anyone else wants to implement the reference change.

Mike: I haven't had time to check the detail on the rest of this.

Nigel: Unless there are any more issues or pull requests to discuss let's return to the IMSC topic.

IMSC (revisited)

Pierre: On the SDP-US issue the sentence above about EBU-TT-D has the same issue. I'm wondering if we should change that too.

Nigel: That's true.

Pierre: I'm thinking of dealing with that at the same time.

Mike: Having parallel language would probably be the best thing to do but since EBU-TT-D and SMPTE-TT are essential I'm not pushing for that.

Pierre: I'm asking for permission to make the two bullets consistent in language.

Nigel: I agree - please change "should not be present" to "is not present" for EBU-TT-D.

Mike: I'm happy with that.

Pierre: Okay I will do that and you'll see the pull request later today. Thank you.

Nigel: We're out of agenda, also time. Thanks everyone. [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/15 16:08:41 $