- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 15 Jun 2017 16:09:31 +0000
- To: W3C Public TTWG <public-tt@w3.org>
- Message-ID: <D5686D4D.42470%nigel.megitt@bbc.co.uk>
Thanks to all for attending today's TTWG meeting. Minutes can be found in HTML format at http://www.w3.org/2017/06/15-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
15 Jun 2017
See also: [2]IRC log
[2] http://www.w3.org/2017/06/15-tt-irc
Attendees
Present
Nigel, Mike, Pierre, Thierry, Dae
Regrets
Andreas, Glenn
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TPAC 2017
3. [6]IMSC
4. [7]TTML
5. [8]IMSC (revisited)
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<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.
action-497?
<trackbot> action-497 -- Nigel Megitt to Invite csswg to joint
meeting at tpac 2017, with list of topics. -- due 2017-06-15 --
OPEN
<trackbot>
[11]http://www.w3.org/AudioVideo/TT/tracker/actions/497
[11] 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.
IMSC
action-498?
<trackbot> action-498 -- Nigel Megitt to Invite i18n to discuss
imsc 1.0.1 issues -- due 2017-06-15 -- PENDINGREVIEW
<trackbot>
[12]http://www.w3.org/AudioVideo/TT/tracker/actions/498
[12] 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.
[13]Clarified the requirement for processors to implement
reference fonts #245
[13] https://github.com/w3c/imsc/pull/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?
[14]https://github.com/w3c/imsc/pull/245/files#r121123051
[14] https://github.com/w3c/imsc/pull/245/files#r121123051
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.
[15]Attribute syntax definition: missing spaces #221
[15] https://github.com/w3c/imsc/issues/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.
[16]Required spaces between non-terminal components of styling
and parameter attributes (issue #221) #230
[16] https://github.com/w3c/imsc/pull/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:
-> [17]https://github.com/w3c/imsc/pull/242 Discourage the use
of tab characters in <p> and <span> #242
[17] https://github.com/w3c/imsc/pull/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.
[18]IMSC 1.0.1 comments tracker wiki page
[18] https://www.w3.org/wiki/IMSC1.0.1_Comments_tracker
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:
[19]https://lists.w3.org/Archives/Public/public-tt/2017Jun/0066
.html
[19] https://lists.w3.org/Archives/Public/public-tt/2017Jun/0066.html
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.
[20]SDP-US is listed as a normative reference, but it is not
#246
[20] https://github.com/w3c/imsc/issues/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.
TTML
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.
[21]Issue 0384 streaming ttml appendix #389
[21] https://github.com/w3c/ttml2/pull/389
[22]HTML version
[22] https://rawgit.com/w3c/ttml2/04a3ea7dd0b15e9cb6451f4655a7d1aea38d32de/spec/ttml2.html
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 [23]scribe.perl version
1.152 ([24]CVS log)
$Date: 2017/06/15 16:08:41 $
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[24] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 15 June 2017 16:10:03 UTC