<scribe> scribe: nigel
Glenn: [needs to go after 1.5 hours]
Nigel: [would also like to finish
promptly] I've been invited to attend the PING meeting
... immediately following this one to discuss the call for
horizontal review of IMSC. Others
... are welcome too.
... Today I'd like to review the schedule for next week's F2F
meeting.
... In the last week we've had some development on IMSC, and
some discussed issues
... for TTML but not much change. There's been some issue
discussion on WebVTT too.
... I've received no hints from David, Silvia et al that they
will join to discuss WebVTT issues.
... Any specific points to raise today?
Pierre: 2 issues on IMSC 1.0.1
that we're waiting on folks from i18n on so we need to
find
... a way to reach out to them somehow.
Nigel: OK - maybe the easiest way will be to try to grab them in person next week.
Pierre: Okay - last time Thierry contacting them directly worked well too.
Nigel: If it can wait until next week that would be best I think.
group: [no other points to raise specifically today]
Nigel: When is good for Australia?
Pierre: Their day usually starts around 3pm California time.
Nigel: I'm guessing David Singer
will be at the AC on Thursday so I'll schedule WebVTT for the
Friday afternoon.
... [edits schedule]
Pierre: We ought to try to cover
how to integrating IMSC 1.0.1 features in TTML2, e.g.
fillLineGap.
... We haven't managed to solve it offline.
Nigel: At the moment the schedule
looks like:
... Thursday am: IMSC
... Thursday pm: TTML2
... Friday am: slack time plus CSS WG joint meeting
... Friday pm: Charter, TTML <--> WebVTT mapping, WebVTT
WR comments
Cyril: I will have a call to make
on the Thursday morning. I will check if Netflix can move
things around.
... I will let you know more later today.
Pierre: What's the plan for TTML1 Third Edition and who is working on it?
Nigel: Last week Glenn told us
that he plans to do TTML1 TE but hasn't made any commits
... since May, and would welcome other editorial input.
Glenn: There are few technical
issues if any so it's just a matter of putting the pull
requests
... in.
Pierre: What's the schedule for it?
Glenn: It's lower priority on my
worklist than TTML2 at present.
... I wouldn't mind having other editors take that on.
Pierre: I'll investigate if I can
contribute.
... I see that all the Third Ed issues are labelled as
such.
Nigel: I think they're in a
Milestone.
... One other useful thing is that we may be able to diff TTML1
SE against TTML2 to pull out
... fixes for specific issues.
Pierre: That's a good idea.
Nigel: I don't think there are any updates on the compatibility document?
Cyril: The only updates are I
added links to issues.
... I will try to move the document onto the wiki.
Nigel: Thank you that would be really helpful.
Glenn: On the TTML1 repo, there
are some issues open on the test suite, labelled as Third
Edition Test suite milestone - 11 open.
... And there are 42 open issues against the spec itself. Some
of them have a cross-dependency
... on TTML2 so I will probably be able to work on those to
make sure they get done on
... both sides. First order, having someone looking at the 11
test suite items would be very useful.
Pierre: This is lower priority I think.
Glenn: I agree.
Nigel: I think doing the spec first and then addressing the tests makes sense.
Glenn: There are 14 Discussed and
Agreed so hopefully they can be resolved fairly quickly.
... They would be the first low hanging fruit to work with.
Nigel: There's only one bug that is on the spec and is not discussed and agreed.
Inconsistent implicit duration of singleton span in sequential container. #193
Nigel: It looks like in January you asked to check it again Glenn.
Glenn: Yes, I think I reported it
originally.
... And it's marked as applying to TTML2 as well.
Nigel: By the way, as Chair, just
a reminder that any group member can submit pull requests
... - you don't have to be an Editor.
... Plus as Chair, and in general in W3C, it's good to have
more than one Editor per spec,
... since it derisks succession planning and resource
bottlenecks etc. so I'm always keen
... to receive offers to volunteer as an Editor.
Issue 0406 style semantics #470
Glenn: Last week we discussed
this - I need to finish reviewing this, and will try to get
it
... done in the next day or so.
Nigel: The only thing I'm aware
that's substantive that is missing is fontShear.
... Cyril, you said you would check my interpretation of
tts:fontShear mapping to CSS transform skewX() and skewY()
functions is correct.
Glenn: FYI that's how I
implemented it in TTPE, using SVG's skew transformations. If
CSS
... supports that then it would be a good approach.
github: https://github.com/w3c/ttml2/issues/471
Nigel: Cyril, you said you would check my interpretation of tts:fontShear mapping to CSS transform skewX() and skewY() functions is correct.
Glenn: FYI that's how I
implemented it in TTPE, using SVG's skew transformations. If
CSS
... I also used rotation because certain characters in vertical
mode are labelled as
... requiring rotation by the Unicode technical report on
vertical layout.
Nigel: Is that part of fontShear?
Glenn: The skew functions are for fontShear, the second is for vertical layout.
Nigel: Cyril, Glenn, if you could
add a note on the issue confirming I've mapped the inline
... progression direction to the correct skew function that
would be helpful.
Glenn: I need to update the pull
request for two reasons (editorially) so I believe I can do
that
... and then implement the change.
Nigel: I think that's fine, we discussed this last week.
github: https://github.com/w3c/ttml2/issues/476
Glenn: Pierre asked a good
question, if nested ruby is going to use. I don't know of
anybody
... implementing or requesting this feature. It's in the spec
because it is a technical possibility
... based on the way the Ruby markup works. I believe this is
also true in HTML ruby. I haven't
... seen restrictions on this in HTML or CSS ruby specs.
... It is technically feasible, and I could imagine creating
content that would use it but its
... edge case and I could not imagine using it in a subtitling
or timed text mode at the moment.
... My expectation is it will fall out of the CR process, so we
should at least mark it as at risk in the CR.
Pierre: So just to confirm, Glenn, you're not aware of any Timed Text application for it?
Glenn: I've seen it in typesetting in print but not in subtitling. So it's theoretically feasible.
Pierre: How does it look in print?
Glenn: For example, in Japanese
you can have kanji that annotates other kanji with ruby
on
... the second level of kanji. For example a semantic
annotation in kanji and then a phonetic
... annotation of that semantic annotation in hiragana or
katakana.
... It just happens that TTPE supports it but I haven't created
any tests for it.
Pierre: Thanks for clarifying.
Glenn: It could be in the JLReq.
Pierre: I searched for it.
Glenn: In the mid-1990s it was a
required feature in the work I did on Japanese
typography.
... It was an edge case though.
Pierre: Alright, then the question is if it is used for subtitles and captions.
Glenn: My proposal right now is to plan to mark it as at risk.
Nigel: I noticed on a recent other CR that the exit criteria were 2 implementations for required feature
<cyril> https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-ruby-element
Nigel: and 1 implementation for optional features, so that's an interesting option for us.
Cyril: The above link - if you
scroll down to "Text with both phonetic and semantic
annotations (double-sided ruby) "
... then the section includes nested rubys.
... §4.5.10
<pal> http://fantasai.inkedblade.net/weblog/2011/ruby/
Pierre: I found another example
that is syntactically nested but one ruby is above the
base
... and the other is below.
... How would we achieve annotations both above and below the
base in TTML2?
Nigel: Scroll down to the "Double Ruby" section.
Glenn: That's not ruby on ruby.
Pierre: The markup is nested but the result is not.
Glenn: Right now it would follow
that "San Francisco" double ruby example. There are 3
... base characters that could have been wrapped in rb, and
there's a ruby around the entire text.
... I haven't tested that in TTPE. Syntactically, it has a
container within a container.
Pierre: How would you do that in TTML2 today?
Glenn: You'd have a span
tts:ruby="container" with two children, one another span
tts:ruby="container"
... and the other with tts:ruby="text"
Nigel: So it is the same but with ruby mode expressed in spans.
<cyril> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/rtc
Cyril: The Mozilla documentation above does exactly the same thing using rtc.
Pierre: So the Mozilla example is not nested syntactically.
Glenn: Right now having nested
container spans is prevented by one of the constraints in
TTML2.
... So I wonder if nested ruby is actually supported. I'm going
to need to check this.
SUMMARY: @skynavga to check current nested ruby status in TTML2
github: https://github.com/w3c/ttml2/issues/474
Glenn: I can mark that as discussed and agreed?
Nigel: Yes we did agree on the approach.
Glenn: [marks as discussed and agreed] and [editorial]
github: https://github.com/w3c/ttml2/issues/473
Glenn: Yes, I agree with Pierre that we need to do this.
Nigel: Pierre, you asked for a single feature, right?
Glenn: This is on the ttp:profile element not the attribute.
Nigel: Should it be one feature or three features?
Glenn: The simplest thing would
be one feature like #profile-version-2 or whatever convention I
use.
... Right now #profile is an aggregate of the features that
refer to five different elements.
... I think probably the best thing would be to collect all of
the upgrades to those elements
... and put them in a #profile-version-2 feature but I'd be
open if someone feels we need
... more fine-grained features.
Nigel: I'd consider testability here.
Glenn: If you're implementing the
new TTML2 semantics in this area you're really going to
want
... to do everything that's been added rather than picking and
choosing, so my suggestion
... would be to tentatively aggregate them into a single new
feature designator.
Nigel: That seems reasonable
group: [no counter statements]
SUMMARY: Group tentatively agrees to create a single new feature designator for this.
Glenn: Nigel did you make
progress on tts:wrapOption?
... I was surprised it was complex because wrapOption came from
CSS.
Nigel: I can't remember where I'm
up to with that but I think the processing of white space
... came into this as adding complexity.
... The CSS white-space property controls white space handling
so that interacts with xml:space.
Glenn: We don't support all the
variability in XSL or CSS in this regard and just map
xml:space
... to a particular set of properties that then flow
through.
... So to the extent that wrapOption semantics are dependent on
xml:space then ...
[misses details]
Nigel: If we want
xml:space="preserve" and tts:wrapOption="noWrap" then they are
two
... mutually exclusive values of CSS white-space.
Glenn: Okay... [investigates]
CSS white-space property definition
Glenn: I imagine that one or more
of those XSL properties not in CSS somehow map to the
... CSS flavour of the white-space property.
Nigel: I hope so!
Glenn: Let's take this offline.
Nigel: Agree!
... Other inputs very much welcome.
github: https://github.com/w3c/ttml2/issues/458
Cyril: I proposed to replace the entire §3.4.2 section.
Nigel: That looks good to me. Did you intend to include the editor's note?
Cyril: We don't need to if we
have issues recorded somewhere.
... I know we agreed to have something in TTML1 Third Edition,
so then if we record the
... issues (which I'll make sure they are) then we can remove
the editor's note.
... Shall I submit a pull request?
Glenn: I don't think we need to
have the phrase "TTML2 is designed such that". Why don't
... we just change "is intended to be" to "is"... Can I propose
a PR for these that's maybe a
... little less wordy?
Cyril: Sure!
Glenn: Okay I'll do that today.
SUMMARY: @skynavga to propose a pull request based on @cconcolato's proposal
github: https://github.com/w3c/imsc/issues/147
Pierre: this is super-boring and has a pull request open.
Nigel: I did ask myself the
question of if we decide we need a mixed text and image
profile
... then if we would need horizontal-rl, and thought we
probably would.
Pierre: Absolutely, this is just on the image only profile.
Nigel: I concluded we don't need it on image only also.
Glenn: Is it possible to infer an EBU-TT-D processor profile?
Pierre: yes using the fallbacks in TTML2.
Glenn: OK
Pierre: If you start with only
ttp:contentProfile you always end up with a processor
profile.
... That's why EBU-TT-D ends up as the processor profile in the
TTML2 algorithm.
Glenn: In that case where the
document interchange context provides the profile, not
that
... EBU-TT-D actually publishes a processor profile
document.
Pierre: That is correct.
Glenn: It would be nice for them to do it [publish a processor profile document].
Pierre: I don't think it's necessary for this to work.
Glenn: .. for interoperability reasons.
Nigel: I will take a look at this pull request (w3c/imsc#267)!
github: https://github.com/w3c/imsc/issues/71
Pierre: I've added an example
that fails. But as a stylistic issue I don't like to put
failing
... examples in specifications. I'd rather add something to the
IMSC test suite that provides
... documents at the threshold of the HRM. My inclination is to
close this issue and add to
... the imsc-tests suite documents ones that are at the
threshold. I think that achieves the
... same objective, first providing a test to check that
implementations meet the HRM requirements,
... and secondly allowing people to check they have the same
understanding of the HRM.
Glenn: I have a different opinion
philosophically - counter examples are an important part
... of any formal specification. So I think it's very useful to
have official counter-examples.
Pierre: Maybe in the test suite.
Nigel: In the test suite it is a
positive test for a validating processor that it should
reject
... documents that do not pass the HRM test.
Pierre: I'm concerned about spec
readers assuming that the document is a good one even
... though it is a bad one.
... In the test suite we could have both documents that fail
and documents that are on the threshold.
Glenn: And you might put the failures in a separate folder.
Pierre: Definitely!
... My proposal is to close this issue.
Nigel: Is it okay by you Glenn to have this in tests only?
Glenn: Yes
Cyril: Agreed
RESOLUTION: Close this issue, in favour of adding threshold and fail tests to imsc-tests.
github: https://github.com/w3c/imsc-tests/issues/37
SUMMARY: As discussed in the IMSC spec w3c/imsc#71, we will add HRM threshold and fail tests which are positive tests for validating processors.
Nigel: Thanks all, we'll close now - see you all next week. [adjourns meeting]