See also: IRC log
<scribe> scribe: nigel
Nigel: For today I think the main
topics are IMSC, and moving IMSC1.0.1 to CR, and TTML2
... is there anything else?
Thierry: TPAC
Nigel: The draft schedule has us
meeting on Thursday and Friday, with Web and TV IG
... on Monday, and CSSWG on Monday and Tuesday, with a
suggestion that we invite
... CSSWG for a joint meeting during our meeting at some
time.
Thierry: Will the CSS WG be around on Thursday and Friday?
Nigel: We can ask!
<scribe> ACTION: nigel Invite CSSWG to joint meeting at TPAC 2017, with list of topics. [recorded in http://www.w3.org/2017/06/08-tt-minutes.html#action01]
<trackbot> Created ACTION-497 - Invite csswg to joint meeting at tpac 2017, with list of topics. [on Nigel Megitt - due 2017-06-15].
Nigel: I'd like to get a draft
list of CSS features that we would need for subtitle and
caption
... presentation, arising from our work on TTML generally.
Pierre: For IMSC1 the obvious ones are multiRowAlign and linePadding.
Andreas: What about line gap?
Pierre: Yes and that too now.
Nigel: I suspect Glenn and/or Dae
will be able to list some Ruby features too.
... It would be good to have CSSWG issues open for those
too.
Pierre: Look at #218 on imsc,
which indirectly indicates where there is (not) CSS
support.
... For example rubyReserve and rubyOverhang are not supported
in CSS. I think Dae did
... an initial pass at doing that so it probably makes sense to
start from there.
Nigel: Thank you I will do that.
Nigel: What are our next steps to
move to CR?
... Thierry, you collated some wide review feedback this
week?
Thierry: Yes, since yesterday I
need to do more updates because Pierre has been answering
... more comments so I will continue to update that wiki
page.
Pierre: My suggestion is to run down the list of issues.
IMSC 1.0.1 Wide Review Comments collated Wiki page
Add diff from IMSC 1.0.0 and update substantive-changes-summary.txt #244
Pierre: This is trivial, there's
not much to be said here.
... I'll take care of that at the last minute like last
time.
... The next is:
Recommended character sets considered harmful #243
Pierre: I have both a question of
substance and of process. This question came out of the
... i18n and we were not involved in the discussion being
filed. Part of the issue is there's
... been a misread of the specification, folk reading more into
non-normative text compared
... to normative text. My take is that this is a
misunderstanding, and I'm trying to find the
... best way to resolve the misunderstanding.
... There are two other i18n issues, which fall into a similar
category. How do we resolve those?
Nigel: Were they all filed by Addison?
Pierre: One was, the others by Richard.
Nigel: I'll invite Richard and
Addison to attend this meeting next week so we can talk
through
... the issues and check we understand properly what their
thinking is.
Mike: We could raise pull requests to clarify the language.
Nigel: I agree, that was my
thinking, but I'm worried that we might not address
whatever
... caused the misunderstanding, if we don't discuss it and
find out by conversation.
... I think it will be most effective if we find a way to
discuss this first.
<scribe> ACTION: nigel Invite i18n to discuss IMSC 1.0.1 issues [recorded in http://www.w3.org/2017/06/08-tt-minutes.html#action02]
<trackbot> Created ACTION-498 - Invite i18n to discuss imsc 1.0.1 issues [on Nigel Megitt - due 2017-06-15].
Pierre: In #243 I don't know what clarification can be made.
Requirement to support certain Code Point #241
Pierre: My conclusion is we can
improve the text to refactor the recommendation to use
... certain metrics with the recommendations for certain
character sets. I don't disagree that
... the current text is not the most straightforward. I'm
reluctant to do this in IMSC 1.0.1, so
... since it is not exactly a blocker I would prefer to defer
it to IMSC2.
Andreas: The text is there and I
think it is correct but could be read differently so there
is
... maybe no strict requirement to update it, though it could
help to do so. What would be
... helpful is if the reader is clear that the code points
listed are not ones for which support
... is mandatory, so it is just about the metrics. From the
text you could read that if you have
... this code point and render it then you should produce a
glyph sequence which is identical
... to the reference fonts. Maybe the edge case is that if
someone has no glyph in the font
... for the code point then he may nevertheless render it with
a substitute glyph. So if the
... condition is there (because the glyph is being rendered)
then the glyph sequence
... rendering must be identical to the reference font, which is
circular because it implies
... that the code point must be supported.
Pierre: There are two conditions
- §7.3 Reference fonts only is supposed to apply when the
... glyphs are supported.
Nigel: I never understood it that way.
Pierre: The reference font
section §7.2 says which code points should be supported.
Then
... §7.3 says "if you're going to support a code point for a
reference font AND it is in the list
... in Annex A" then you must end up with the same result, but
it does not compel support
... for all the code points.
Andreas: Would it be possible to
add explicitly a condition that it only applies when all
... the code points are supported by the font used to meet the
reference font requirements?
Nigel: +1
Pierre: I don't think that would
be controversial - it is the intent already. I would be
happy
... to clarify that.
... [adds a note to the issue] I will generate a pull request
that clarifies this.
Clarify "All regions shall not extend beyond the root container" #239
Pierre: There's a pull request open for that.
Nigel: I just added an approval for that (it was wording suggested by me).
Why exclude hebrew and arabic proportional reference fonts? #237
Pierre: This is an i18n comment.
I think we ended up rewording one of the sentences and
... Nigel you suggested a tweak, so I'm tempted to generate a
pull request to use as input
... to our discussion.
Nigel: Makes sense.
Pierre: I will generate a pull request [adds note].
Should the character sets be minimum *font* requirements? #236
Pierre: The recommended character
sets is worded as an authorial requirement rather than
... a processor requirement. This occupied a lot of discussion
for IMSC 1 so I'm reluctant in
... IMSC 1.0.1 to change it into a processor requirement.
... I propose a "won't fix" for IMSC 1.0.1 and add it to the
list of things to discuss with i18n.
Nigel: Ok.
imsc1-all.xsd has a bad pointer for SMPTE-TT schemas #235
Mike: The current IMSC 1 uses the
SMPTE 2010 namespace and I'm on a mission to develop
... some tight schemas for IMSC 1. When I started digging into
this I discovered that the
... backgroundImage wasn't documented until the 2013 namespace,
so if you were to try
... to write a comprehensive schema you would get stuck there.
It is trivial of course, as per
... the email I sent. The question is how to go about
addressing this. We could write to
... SMPTE and note that 2010 is missing backgroundImage, but
the answer would probably
... be to use 2013. Or we could write it ourselves but it would
be a little weird to write
... something in the SMPTE namespace.
... It would be disruptive to switch to the 2013 namespace
because it is incompatible
... with the 2010 namespace.
Pierre: To Mike's suggestion, we or SMPTE could conceivably create a 2010 schema.
Mike: All we need is one attribute of type xs:anyURI.
Pierre: We either create that one
definition and move on, or get SMPTE to write it so that
... they have control of it.
Mike: There's maybe a hybrid where we ask SMPTE to do it but offer to do the work.
Pierre: Or we could create it, send it to SMPTE and ask them to publish it.
Nigel: This is informative only. [traces through the SMPTE references]
Mike: There's an example in ST2052-1-2010 where smpte:backgroundImage has a URI
Nigel: I see there's a
substantive issue here in that the normative specification
isn't completely
... clear that backgroundImage takes a URI, though it can be
inferred. Possibly we need to
... add a clarification to IMSC1.0.1. On the schema, which is
informative I'm not so bothered.
Mike: That's why 2013 was done! I
think it would be good to clarify in IMSC 1 and offer a
... proposed update to the 2010 schema to include it. While
we're writing to SMPTE we can
... also ask to verify that it is supposed to be an
xs:anyURI.
... I'll draft the liaison to SMPTE, and we ought not to touch
IMSC1 until we get an
... answer back and then there will probably be a follow-up
action to modify the spec.
Nigel: [adds note to issue]
Mike: Aside from this issue, the
question I have for this group is, if I write all these
schemas
... and post them as a contribution, how do we attach them to
IMSC1?
Nigel: We can just add it to the
linked documents we publish. Another alternative is we
... could create a new repository just for the schemas and link
to that. It is much easier for
... people to use that way too.
Mike: Sounds good to me.
Pierre: +1
Mike: Then it provides a good way to update it in case any changes are proposed later.
Nigel: Agreed.
... Should we add a new repo?
Pierre: The schemas are already
in the spec repo. We could keep it there as a directory
... and when it feels right to create a repo, do that. We can
do everything we want on a
... separate branch on the IMSC repo and when we're ready
create a separate repo.
Mike: I like the first part, maybe we don't need to create a new repo.
Nigel: Okay, works for me.
Recommend avoiding tab characters #232
Pierre: There's a pull request:
-> https://github.com/w3c/imsc/pull/242 Discourage the use of tab characters in <p> and <span> #242
Pierre: As you point out Nigel,
it seems valuable to explain this unusual exception. I
also
... do not like informative text. Glenn seems to oppose it.
Nigel: Glenn says a note would be acceptable but bad practice.
Pierre: I'm happy to not have it, put it in the text or put it in a Note.
Nigel: I prefer to put it in a Note.
Pierre: The text will say "should
not use the TAB character" and the note will say that no
... presentation semantics are specified for the code
point.
NIgel: +1
Pierre: [adds note to pull request]
Determination of the color in leading in tts:fillLineGap #228
Pierre: I left the ticket open
because we need disposition comment from the commenter,
... but we have a conclusion in the group.
Nigel: Where did this come from originally?
Pierre: From the ARIB liaison.
Nigel: I believe that we only
need to send a message back to the commenter explaining
... the disposition, and offering a last opportunity to
comment.
Mike: We can send a link to the ED to make it easier, and to the issue.
Nigel: Yes.
Thierry: We don't need to publish a new WD say.
Nigel: We have so few comments here I don't think we need a tool.
Thierry: Yes, I think manually
will be good enough. We can use GitHub also, if the
commenter
... adds a note.
Nigel: That's good for i18n say but not for ARIB.
Thierry: So for ARIB we will send an email.
ittp:activeArea clarification #227
Pierre: this is in the same
category as the previous one - we have agreement here, and
need
... to confirm the disposition.
Create tests for CR exit criteria #226
Pierre: I created the tests, so I think we can close this.
Nigel: Can we review what the
exit criteria actually are? They're the same as we used
for
... IMSC1, right?
Pierre: This has actually been merged into the ED.
<pal> http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html
Pierre: It is the same as we used in IMSC1 but only applying to new features.
Thierry: Looks good to me.
Nigel: The implementation report is a wiki page.
Pierre: Like for IMSC1.
Nigel: The Exit Criteria Test Suite is a 404.
Pierre: Yes that is because github.io won't let you browse directories - it needs to point to
<pal> https://github.com/w3c/imsc/tree/master/imsc1/spec/exit-criteria-tests
Pierre: That directory has TTML files and PNGs.
Nigel: And the examples match what is in the spec for fillLineGap.
Thierry: And there are just two.
Pierre: I think that is sufficient for this particular case.
Thierry: Yes.
Pierre: Especially since the fillLineGap test is pretty gnarly.
Nigel: Agreed.
... Any other comments?
group: [silence]
Nigel: Okay that's a decision to accept those proposed CR exit criteria and test suite.
Thierry: If we need more tests we can add them later.
Pierre: [closes issue]
Attribute syntax definition: missing spaces #221
Pierre: This is contingent on
whether or not spaces are allowed alongside delimiters in
... tts:fontFamily. I think we are getting close to a
resolution, so when we get there I will
... generate a pull request for IMSC1.
... I have not seen any comments back on the reflector about
this issue.
Nigel: Me neither.
Pierre: And Nigel and Glenn prefer option 2 so I think we will go with that.
Nigel: If we have not had any
more comments by this time next week shall we just go
with
... that option?
Pierre: Yes.
Copy referenced schema to the schema directory for ease of validation #212
Pierre: We are waiting on you for this Nigel. The last I heard you were going to give it a try.
Nigel: When I tried this I got
into all sorts of trouble but I accept that it *should*
work
... without copying the referenced schemas in.
... [closes issue]
Andreas: [leaves]
Pierre: That completes the review of IMSC 1.0.1 issues scheduled for CR.
Nigel: So the next step is to
complete the disposition with i18n and write to ARIB
about
... two issues. Thierry please could you find the usual
boilerplate, and send it to Pierre?
Thierry: Yes I will do that tomorrow.
Pierre: I will draft the email.
Nigel: Thank you both.
Appendix R [June 4 ED] is overly constrained and does not represent current best practice #384
Nigel: I'm preparing a pull
request for this.
... I'm concerned that progressive decoding is not always
possible.
Mike: My concern is that all of
the text in the appendix should be removed, so I'd like
to
... start there, and then if someone argues the existing text
is fine then discuss that.
Nigel: That works for me.
... I plan to add a section referencing ISOBMFF and EBU-TT Live
explaining the temporal
... fragmentation approach used there.
Mike: I would like to take the
TTML1 approach out and just reference it as an
alternative.
... Then this appendix is shorter. I know there's a document by
Cyril about this.
Nigel: Oh yes that's on github,
written by Romain, Cyril and me. We could reference that
... informatively.
Mike: I'm concerned about how stable that is though.
Nigel: Okay I understand, I'll
submit a pull request along those lines for review.
... I'll put a picture in too, because that's always
helpful.
Mike: That sounds fine.
... And rather than perpetuate the fragmentation mechanism,
just point back to TTML1.
Nigel: Okay I'll make some changes and make that happen.
Support for conditional styling. #128
Nigel: I just want to check with
you about this even in the absence of Glenn.
... Is it okay not to be able to conditionally select a region
for content based on whatever
... input parameters are available? I think it might be because
the properties of the selected
... region can be conditionally set without having to choose a
whole different version.
... Otherwise we might end up needing to change the region
attribute to IDREFS.
Pierre: I need to see use cases for this otherwise I don't know how to evaluate it.
Nigel: Makes sense to me. The way
I'm thinking right now is that using condition to support
... media queries (screen size) and user preferences (e.g. text
size) would be helpful, even
... in IMSC2 perhaps. But I'm not settled on a firm viewpoint
on that just yet.
Mike: I second Pierre's concern here that we need to understand the requirements.
Nigel: Okay I agree that we need
to address practical considerations primarily, and I
haven't
... any evidence so far to say that we should make any more
changes relative to what is
... present currently.
... So I will not open a new issue on this right now.
... On the issue of foreign namespace elements and where they
can go, we discussed
... it in the context of IMSC 1 and TTML1 but there's no issue
for it in TTML2 as far as I can
... see. Maybe one is needed.
... I'm hesitant to raise an issue without checking that there
actually is one, in case
... changes have already been made to TTML2.
Mike: I can do that right now.
Nigel: Thank you.
... I think we've run out of agenda, a little ahead of time, so
I'll close for today.
... Thank you all! [adjourns meeting]
/