- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Mon, 20 Nov 2017 12:02:11 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D63874B7.4E633%nigel.megitt@bbc.co.uk>
All,
Thanks to the many of you who were able to attend our face to face meeting at TPAC this year. Although I attached a link to the minutes to our wiki home page at the time I did not send them out, so doing so now.
Minutes in HTML format: https://www.w3.org/2017/11/09-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
09 Nov 2017
Attendees
Present
cyril, ericc, atai, pal, nigel, tmichel, glenn,
astearns, florian, wdh, fantasai, rossen, hober, plinss,
dbaron, wseltzer, dsinger, silvia, chris_needham(BBC)
Regrets
Chair
Nigel
Scribe
nigel, dsinger
Contents
* [2]Topics
1. [3]Agenda sweep
2. [4]Introductions
3. [5]Agenda topics
4. [6]IMSC vNext Reqs: Require profile signaling #10
5. [7]Ethics and Professional Conduct reminder
6. [8]Updated profile signaling and resolution to match
TTML2 semantics #267
7. [9]What fillLineGap does/ affects #254
8. [10]Should UTF-8 'as specified in' point to the
Encoding spec? #253
9. [11]Meaning of 'glyph area descendant' #236
10. [12]Ruby align 'withBase' semantics #248
11. [13]NR is less than NB and NB is equal to 1 #249
12. [14]TTML2 Ruby alignment with HTML and CSS
13. [15]tts:fontVariant is needed to select half vs full
variants in Japanese text #6
14. [16]Break for lunch
15. [17]back after lunch
16. [18]Should ebutts:linePadding be deprecated? #278
17. [19]Should ebutts:multiRowAlign be deprecated? #277
18. [20]Break
19. [21]Add parameters to define the temporal extent #483
20. [22]Add ttm:mediaTimestamp (or equivalent) attribute
#125
21. [23]Back to IMSC 1.1 issues...
22. [24]Should ittm:altText be deprecated? #274
23. [25]Should itts:forcedDisplay be deprecated? #279
24. [26]Should itts:fillLineGap be deprecated? #276
25. [27]ttp:displayAspectRatio is prohibited #273
26. [28]Meeting close
27. [29]Introductions
28. [30]This meeting
29. [31]CSS meeting prep
30. [32]Web platform tests
31. [33]Should ittp:activeArea be deprecated? #275
32. [34]Deprecation of smpte:backgroundImage in favor of
tt:image #259
33. [35]Should ittp:progressivelyDecodable be deprecated?
#272
34. [36]IMSC 1.1 issue wrap-up
35. [37]CSS WG and TTWG joint meeting
36. [38]Japanese features
37. [39]Line based styling
38. [40]Wrap up, next steps
39. [41]Break for lunch
40. [42]TTML1 Third Edition
41. [43]Timelines for transitioning our specs
42. [44]IMSC 1.0.1 timeline
43. [45]IMSC 1.1 timeline
44. [46]Charter 2018
45. [47]TTML <--> WebVTT mapping
46. [48]ttp:version
47. [49]Break - return in 20 minutes
48. [50]WebVTT
49. [51]Wide Review Comment 2017: Text color must be
mandatory #365
50. [52]general discussion
51. [53]https://github.com/w3c/webvtt/issues/378
52. [54]https://github.com/w3c/webvtt/issues/376
53. [55]https://github.com/w3c/webvtt/issues/373
54. [56]Meeting wrap-up
* [57]Summary of Action Items
* [58]Summary of Resolutions
__________________________________________________________
Agenda sweep
<nigel> nigel: Will break at 1500 and other times.
<nigel> cyril: Timeline for getting TTML2 to CR?
<nigel> glenn: Should discuss that.
Introductions
<nigel> glenn: Glenn Adams, Skynav
<nigel> cyril: Cyril Concolato, Netflix
<nigel> tmichel: Thierry Michel, W3C Staff contact
<nigel> nigel: Nigel Megitt, BBC
<nigel> pal: Pierre Lemieux, supported by Movielabs
<ericc> Eric Carlson, Apple/WebKit
<nigel> atai: Andreas Tai, IRT
<nigel> flick: Chris Flick, Apple
<nigel> ericc: Eric Carlson, Apple
<nigel> scribe: nigel
dsinger: David Singer, Apple
Agenda topics
Nigel: [iterates through topics]
pal: We can probably do IMSCvNext reqs pull request #10
... On TTML2 there are some issues ongoing we can discuss.
Nigel: MediaOffset
pal: Another one is IMSC 1.1 pull request on profile signalling
and resolution #267
IMSC vNext Reqs: Require profile signaling #10
[59]IMSCvNext Pull Request #10
[59] https://github.com/w3c/imsc-vnext-reqs/pull/10
pal: This came from Glenn's review of the requirements document
github: [60]https://github.com/w3c/imsc-vnext-reqs/issues/5
[60] https://github.com/w3c/imsc-vnext-reqs/issues/5
pal: Looking at the long thread on the PR, trying to solve the
problem of signalling of profile
... in the requirements document is probably not the right
place to do it. It's too complex.
... In the requirements all we need to say is that the profile
signalling mechanism in TTML2
... should be used whenever possible.
... This matches a pull request already open on IMSC 1.1.
nigel: Yes, the requirements document needs to be appropriately
scoped.
pal: The change now is "The profile resolution semantics and
signaling specified in [[!TTML2]] SHOULD be used whenever
possible."
RESOLUTION: Approve IMSCvNext requirements pull request #10
pal: Thanks! I'll merge it.
Ethics and Professional Conduct reminder
nigel: I've remembered Chairs have been asked to remind group
members that we are
... working within a code of ethics and professional conduct,
so Be Good People!
[61]Code of Ethics and Professional Conduct
[61] https://www.w3.org/Consortium/cepc/
Updated profile signaling and resolution to match TTML2 semantics
#267
github: [62]https://github.com/w3c/imsc/pull/267
[62] https://github.com/w3c/imsc/pull/267
glenn: I'd caution against paraphrasing what's in TTML2
pal: That's the goal, to avoid doing that.
... §7.8: This is about signalling profile conformance in the
document.
glenn: Just to check the intent is to signal the content
profile and the inferred processor profile?
... I'm wondering why you chose the content profiles path. It's
okay, you get both that way.
pal: Yes, the profile resolution semantics always lead to a
processor profile anyway.
glenn: Because of the way the inference process works in TTML2
you may want to review
... this for any implications that are not wanted. You might
want to assume something, the
... defaults, for those things that are prohibited.
pal: We'll add that in §5.4.
nigel: That's a good call - we've been tripped up by that kind
of thing before.
glenn: Yes, especially when you prevent the author from making
the statements.
nigel: Note a structural issue with this, referring to
following sections unscoped.
atai: Maybe list the specific section numbers.
pal: Okay, I've made a note.
... OK, then if you want IMSC 1 compatibility.
... This mimics what's in IMSC 1 today.
glenn: Processing compatibility of document conformance
compatibility?
nigel: What does it mean to say a document instance is
compatible with a processor profile?
pal: IMSC 1.0.1 processor can successfully process the document
instance
nigel: Maybe we don't need the "and compatibility with 1.0.1
processors is desired" clause?
pal: No because contentProfiles is not prohibited by 1.0.1
nigel: But if it is allowed in 1.0.1 then why don't we make it
a SHOULD NOT be present
... rather than a SHALL not?
pal: We don't want to add confusion in the marketplace by
permitting TTML2 syntax in
... TTML1 documents.
glenn: Propose adding a note to help a reader understand why
there's a shall in one place
... but a shall not here.
... Something about the intent, otherwise it seems like a
strange thing.
pal: Nigel objected to the "mutually exclusive" wording.
nigel: I don't mind stating they're mutually exclusive, but the
way it was done was confusing.
... Playing devil's advocate here, we generate a state where a
conformant IMSC 1.0.1
... will become a non-conformant IMSC 1.1 document if
ttp:contentProfiles is present?
pal: Correct
nigel: Wasn't it one of our design goals to avoid that?
atai: I think ttp:contentProfiles is not conformant IMSC 1.0.1
because it's not vocabulary permitted in TTML1.
... TTML1 only allows content within its own model.
nigel: That flips the scenario completely - it means that the
current text is correct.
pal: Glenn, is this correct that ttp:contentProfiles is
prohibited in TTML1?
glenn: We have an issue in TTML1 on this, but we did not nail
down the use of vocabulary
... in existing TTML1 namespaces.
atai: The schema design prevents adding arbitrary content being
added to TTML1 namespaces.
glenn: That's not correct, in that the notion of validity in
TTML1 is assessed after removing
... all unknown vocabulary, so we can only talk about content
compliance in TTML with
... respect to the post-processing state of an abstract
document instance in the infoset, at
... which point all unknown vocabulary has been removed. So you
can't tie it to a schema.
... This language has an issue - w3c/ttml1#251
<glenn> [63]https://github.com/w3c/ttml1/issues/251
[63] https://github.com/w3c/ttml1/issues/251
glenn: It's my contention that the appearance of TTML namespace
vocabulary not defined in TTML1
... should not cause that document to be non-conformant. That
includes TTML2 vocabulary,
... which would simply be removed by a TTML1 proessor.
nigel: In that case can we change the SHALL to a SHOULD.
pal: Okay, let's make it a SHOULD NOT.
... Continuing: EBU-TT-D compatibility
nigel: Just an editorial tweak - it's not a single
conformsToStandard element, there are
... possibly multiple, but at least one of them needs to
include the 1.0.1 designator.
pal: There's a note here too.
atai: In EBU-TT-D 1.0.1 there will be a new URI for
conformsToStandard so we need to update that.
nigel: Also the reference will move from EBU-TT-D to EBU-TT
Part M.
pal: Need to raise issues for those please.
... SDP-US compatibility
... Not much to say here.
nigel: It's pretty simple!
pal: Now §5.4 Profile Resolution Semantics
... All the TTML2 algorithms apply including the ones in the
TTML2 pull request that introduces the "override profile" term.
... The TTML2 algorithm gives you the processor profile.
glenn: Does IMSC ever specify a profile definition document?
pal: No it's inferred.
glenn: I recommend coalescing that data into a profile
definition document in the appendix.
pal: That would require a new extension for every additional
constraint, which is a pain.
nigel: Who would it be useful for?
glenn: Implementers and authors. I take the point that creating
new extension features would be difficult.
atai: It is done this way in IMSC 1
pal: I've had no requests for a profile definition document for
IMSC 1
nigel: Summarising, we did not agree to add a profile
definition document for IMSC 1.1.
pal: §5.4.2 Override
nigel: Hung up on the wording of the 2nd/3rd para
pal: Yes, I need to update that to deal with there being
multiple elements each with a single value.
glenn: The first sentence seems to duplicate TTML2.
pal: Those statements are not present in TTML2
glenn: There's an algorithmic approach that I think ends up
with this.
pal: I could not find it - for example TTML2 is silent on how
to set the override content
... profile. It just says what to do if it is set.
glenn: I see, so this is providing a mandatory link between the
presence of a profile in
... the context and the override profile.
pal: Yes
glenn: Is there an ordering? What if both the statements are
true and resolve to different override profiles?
nigel: We have to deal with that, they could easily both be
true and different.
glenn: I would remove the "or the document interchange
context".
... TTML2 §5.2.4.2 (merged this morning) deals with this
pal: That step 1 needs to additionally include the document
interchange context
glenn: The way the document processing context is obtained is a
black box, a processor
... might choose to use the document interchange context.
... In my mind the current language in TTML2 permits what you
need.
pal: Not explicitly - in HbbTV for example the profile is set
outside the document processing,
... it just says to treat the document as an EBU-TT-D document.
... Sometimes the document comes in without any inband
signalling.
glenn: The semantics of specifying a content profile are useful
for 2 purposes, one is
... for validation processing and the other is for inferring a
processor profile.
... There's already language in the construct default processor
profile that does take into
... account the document interchange context, so that means
you're adding to validation
... processing, where a processor would override any
consideration of content profile that
... the author may have specified.
pal: If I specify no content profile, and the document
interchange context specifies a processor profile,
... then your argument is that it applies to [construct default
processor profile]?
glenn: Correct. The reason I wrote this is because I didn't
want to allow the processor to
... override the determination of the content profile based
solely on the document interchange
... context.
nigel: Why not?
glenn: Because it would mean for determining the default only
the interchange context would override the authorial intention.
pal: We can change the first sentence in §5.4.2 Override. I
propose to remove it, and move
... the example to the previous section §5.4.1 General
glenn: That works for me.
pal: Just to understand, in the example, the DASH manifest sets
the default processor profile
... not the override content profile?
glenn: Correct.
pal: That's all on this pull request, I have all the actions I
need to close this.
<r12a>
[64]https://lists.w3.org/Archives/Public/www-style/2017Nov/0006
.html
[64] https://lists.w3.org/Archives/Public/www-style/2017Nov/0006.html
What fillLineGap does/ affects #254
github: [65]https://github.com/w3c/imsc/issues/254
[65] https://github.com/w3c/imsc/issues/254
[66]IMSC1.0.1 fillLineGap
[66] http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html#itts-fillLineGap
pal: There are more examples of this in the IMSC spec now,
compared to when the issue
... was raised.
glenn: This might depend on if the line area includes leading
or not. In our model it does
... include the leading.
... We assume that line areas abut each other.
pal: That's how CSS works, it stacks the line areas with no
gaps between them.
glenn: The issue raiser's model may differ, so it may be worth
clarifying.
nigel: I think the main concern is that it could cause parts of
letters or symbols to become
... effectively invisible.
r12a: I was looking at that too - need to think about ascenders
and descenders, which in
... some languages like arabic can be quite long.
... I think the question is if the background definitely
extends to cover those.
pal: That goes back to XSL and CSS - this section doesn't
change that at all.
... It sounds like the concern does not relate to fillLineGap
specifically, but to the application
... of background on span.
glenn: There's a valid point, which is can the author avoid
doing something stupid or is it
... an instruction to implementers. It sounds like his concern
is we could force the processor
... to do something that makes the author do something to
address visibility of glyphs.
... In fact there's no constraint in any of the specs that the
outline of the glyph be inside the
... em square. This is the case where the author needs to be
aware of that.
pal: fillLineGap does not make this worse because it does not
apply new background, it
... only extends existing background, so it can't make anything
worse, only better.
... Example: white glyphs, black background, which is extended
to cover parts of glyphs that
... overlap non-background.
... The line stacking strategy means the line height must be
greater than or equal to the computed lineHeight.
r12a: In CSS you can set lineHeight to 0.5 and the glyphs may
overlap each other.
atai: In the line stacking strategy in TTML that is prohibited.
pal: On this issue I propose to clarify that fillLineGap does
not add background but extends
... existing background.
nigel: I think the point to clarify is that the line area
before edge and after edge can never
... be within the content rectangle, so there can never be a
case where setting the background
... to the before and after edges of the line areas makes the
background get smaller
... than it would be without fillLineGap.
atai: I propose to add a note to the spec section to say that
the application of fillLineGap
... does not result in hiding any characters that would be
visible without fillLineGap.
nigel: I propose to add a note that the line stacking strategy
for TTML means that the
... application of fillLineGap can never make the background
smaller than if it were not applied.
r12a: Another way to say it is that the background that is
applied will cover all parts of all the glyphs.
atai: Yes, to say after application of fillLineGap all parts of
all glyphs with a background
... colour behind them continue to have that background colour
applied.
pal: I'll propose text.
<cyril> what about ruby?
pal: this is IMSC 1.0.1
glenn: I'm not sure I've defined that very carefully for
presentation semantics of TTML2,
... but I have the assumption that ruby glyphs are contained
within the line area.
RESOLUTION: Add a note to say: Note: The application of
fillLineGap does not result in hiding any character glyphs that
would be visible without fillLineGap. Therefore after
application of fillLineGap all parts of all character glyphs
with a background colour behind them continue to have that
background colour applied.
Should UTF-8 'as specified in' point to the Encoding spec? #253
github: [67]https://github.com/w3c/imsc/issues/253
[67] https://github.com/w3c/imsc/issues/253
glenn: My response is "no" it should point to Unicode.
r12a: The first question is does it have to point anywhere?
People don't normally reference
... a definition of UTF-8.
glenn: There are different definitions of UTF-8 so we need to
nail which one we mean.
... All current TTML specs refer to Unicode for that
definition.
r12a: Unicode defines UTF-8, the encoding specification defines
it in terms of conversion
... between legacy encodings and UTF-8 code points, but does
not define UTF-8 per se.
... Which of those do you need or want?
glenn: We don't refer to legacy encodings anywhere so we don't
have a normative requirement
... to say anything. There's just UTF-8, and how it got there
is outside of the scope.
atai: How does HTML5 handle this?
nigel: It seems like nobody thinks we need to make any changes
here?
<cyril> regarding the previous resolution, there should be
matching normative behavior that produces what the note says.
You cannot simply have a note that says "does not result"
RESOLUTION: We do not need to refer to the Encoding spec and do
not need to make any change.
nigel: I can't label this because the labels aren't on the repo
for WD tracking.
... I've raised #282 for Thierry to add them.
Meaning of 'glyph area descendant' #236
github: [68]https://github.com/w3c/ttml2/issues/236
[68] https://github.com/w3c/ttml2/issues/236
Nigel: Would switching "glyph area descendant" to "descendant
glyph area" help?
r12a: Yes it would help a bit - now I understand you mean the
first descendant that is a glyph area.
... And that you don't mean a descendant of a glyph area.
glenn: I could add a note to the definition of glyph area to
say that glyph areas have no descendant areas
... I could also add a Note to §10.2.3.7.
r12a: Would you consider "which is" before each "descendant"?
glenn: I could do that.
... I also note that the third instance of "glyph area
descendant" in that section doesn't say what it is a descendant
of.
RESOLUTION: Add "which is a" before "descendant".
r12a: I will review the definition of glyph area from the pull
request too.
... Where the text says to count the glyph areas, what is a
glyph area?
glenn: In the area tree there are a number of glyph areas, but
the question is how is that
... tree constructed. This algorithm doesn't define that, it
assumes it has already been constructed.
... It's viewed as being outside the scope.
nigel: Any other implementers here who need to construct the
area tree?
cyril: Yes, we have done it for Japanese.
r12a: That's the easy case.
glenn: I wanted to avoid saying anything about graphemes here
and keeping it on the topic of layout.
r12a: It is much less likely that there would be arabic or
hindi ruby which would be a more complex case.
glenn: There may be other open issues that are affected by this
too.
pal: How does this compare with what CSS does?
r12a: CSS doesn't talk about glyph areas at all.
glenn: They leave that to implementation details.
r12a: They don't have to count things.
glenn: They don't have a withBase alignment.
r12a: Correct.
flick: Or height in vertical flows.
r12a: The context here is withBase that requires counting.
glenn: The JLReq does go into this area, talking about sizing
effects of 1 vs 2 vs 3 ruby
... associated with a base, which in Japanese typography there
are conventions for.
... This doesn't go that far but it does start going further
than CSS.
cyril: CSS talks about boxes rather than glyph areas, and the
alignment is based on boxes.
glenn: They're synonyms - XSL uses "area", CSS uses "box" to
mean the same thing.
cyril: Netflix doesn't use "withBase" so possibly a solution
would be to defer this functionality.
r12a: We were quite surprised about withBase. My understanding
is that this withBase is a
... thing that lambdaCap does so it is in the spec.
glenn: It came out of my analysis of what would be needed to
support lambdaCap.
pal: If there are no lambdaCap files including it, then it
would be safer to put it at risk or remove it.
nigel: We are working towards CR now so we could mark it at
risk now.
flick: That would be a signal to people who are interested.
RESOLUTION: Mark rubyAlign="withBase" as at risk for CR
glenn: If it is an optional feature and our exit criteria
require one implementation of each
... optional feature then this is already satisfied.
r12a: I checked my dictionary for any examples where this would
apply, and could not find any.
... Either in Japanese or with Pinyin. So it was all a bit
weird to me.
glenn: I'm pretty sure there's language on this in the
lambdaCap spec also.
Ruby align 'withBase' semantics #248
github: [69]https://github.com/w3c/ttml2/issues/248
[69] https://github.com/w3c/ttml2/issues/248
cyril: Netflix doesn't use "withBase" so possibly a solution
would be to defer this functionality.
r12a: We were quite surprised about withBase. My understanding
is that this withBase is a
... thing that lambdaCap does so it is in the spec.
glenn: It came out of my analysis of what would be needed to
support lambdaCap.
pal: If there are no lambdaCap files including it, then it
would be safer to put it at risk or remove it.
nigel: We are working towards CR now so we could mark it at
risk now.
flick: That would be a signal to people who are interested.
RESOLUTION: Mark rubyAlign="withBase" as at risk for CR
glenn: If it is an optional feature and our exit criteria
require one implementation of each
... optional feature then this is already satisfied.
r12a: I checked my dictionary for any examples where this would
apply, and could not find any.
... Either in Japanese or with Pinyin. So it was all a bit
weird to me.
glenn: I'm pretty sure there's language on this in the
lambdaCap spec also.
... I think withBase may be being used under the covers in the
Netflix implementation without it being obvious.
... The currently defined auto semantics for rubyAlign is based
on withBase when Nr = Nb.
... That encodes the lambdaCap semantics in the semantics for
auto.
cyril: But we are requesting that auto be changed to center.
nigel: And that doesn't use withBase?
glenn: No, when center is used it doesn't use withBase
semantics, it doesn't distribute any space between the ruby
glyphs.
cyril: We'll take it offline and come back with an issue.
NR is less than NB and NB is equal to 1 #249
github: [70]https://github.com/w3c/ttml2/issues/249
[70] https://github.com/w3c/ttml2/issues/249
cyril: rubyAlign="auto" when the number of rubys is less than
the number of base glyphs:
... when the base characters is 1, use space around, or for
greater than 1, use space between.
... But when there is only one base glyph, the number of ruby
glyphs must be 1 too, so there's
... no difference in that degenerate case between space between
and space around.
... If we resolve to use the semantics of "center" for the
semantics of "auto" in all cases then this issue goes away.
r12a: Regardless, this is still odd text.
cyril: Is there a difference between space around and space
between when there is only
... one glyph area?
glenn: There would be nothing to put between, so I don't think
so.
nigel: I've raised #489 for the "otherwise" applying too
broadly.
<glenn> see
[71]https://www.w3.org/TR/jlreq/#ruby_and_emphasis_dots for
discussion of ruby alignment
[71] https://www.w3.org/TR/jlreq/#ruby_and_emphasis_dots
TTML2 Ruby alignment with HTML and CSS
ericc: Is there a plan to align TTML2 ruby with HTML?
nigel: I think there's a syntactic mapping from TTML2 to HTML
here, but there may be some CSS issues.
cyril: That's for tomorrow - I've been discussing with CSS folk
and there may be existing
... ways to achieve the ruby semantics in CSS that we weren't
aware of before.
<cyril> [72]https://www.w3.org/wiki/TimedText/CSSRequirements
[72] https://www.w3.org/wiki/TimedText/CSSRequirements
[73]CSS Requirements gaps analysis
[73] https://www.w3.org/wiki/TimedText/CSSRequirements
r12a: We have concerns about nested rubys. i18n has a plan to
simplify the ruby content
... model by taking out nesting for example. The default would
probably be to use the tabular
... approach as opposed to the interleaved approach.
... The tabular approach is clearer and has some advantages
strategically for CSS. It's only
... supported in Firefox unfortunately at the moment.
glenn: I would imagine tabular is better for parenthetic
presentation too.
r12a: Yes
... If you had To kyo (to) (kyo) with the interleaved model you
would end up with To (to) Kyo (kyo)
... This is a "gleam in our eye" at the moment.
Nigel: One anecdotal data point from a chat yesterday with a
Japanese consultant, who pointed out
... that often the inline markup of Ruby for captions is easier
to read because the ruby glyphs
... are bigger.
cyril: If we are going to make changes like this, to be
applicable for CSS, WebVTT, TTML etc
... what does it mean for TTML2? Should we change the content
model?
r12a: The timing is unfortunate.
pal: There could be a future version of TTML
cyril: Should we spend time working on this now though?
r12a: Go ahead with what you have. Your implementation of ruby
is fairly simple anyway,
... since you're not using nesting.
flick: Are there any particularly complex ruby implementations
to mark as less used and
... for solving later?
r12a: Yes there may be some, I'm not sure what they are, maybe
double sided ruby where
... the top doesn't have the same application as the bottom but
they overlap.
pal: I'm keen to remove features we aren't sure of. It's more
harmful to include it now
... as opposed to removing it now and then adding it back in
if/when we need it.
tts:fontVariant is needed to select half vs full variants in Japanese
text #6
github: [74]https://github.com/w3c/imsc-vnext-reqs/issues/6
[74] https://github.com/w3c/imsc-vnext-reqs/issues/6
r12a: There are no half width Unicode latin characters.
pal: Are we happy with the variations offered by Unicode alone
or do we also need fontVariant?
r12a: CSS does stretch and shrink and JLReq says always make
say "2017" fit within the line.
pal: TTML says the renderer should make it fit. Glenn also
suggested using tts:fontVariant,
... and @ @
glenn: Sometimes fonts offer more legible versions of half and
full to make ruby more readable.
... The question is do we need fontVariant when it may be
satisfactory to use Unicode.
pal: Yes, and the recommendation to tell the renderer to make
things fit.
glenn: In TTML2 I assumed the author would not do anything
special to choose full or half
... width in tate cho yoko context, so I view that as
orthogonal to the fontVariant question.
... I would ask more if super and sub are useful, because
there's no Unicode solution to that?
nigel: I have an issue open about the tnum Opentype options.
Would they go in fontVariant?
glenn: They could do. fontVariant doesn't include all the
general font mechanisms. However
... there are arguments that it is too font specific. The CSS
spec allows specification of the
... particular truetype table parameters.
... If you want to support tnum, and any of those other
features, then it would drive you
... to the generic solution. If you are convinced there's only
a small set of specific variants,
... then the keyword approach is more useful.
... I prefer the general mechanism rather than keywords. Then
we could simplify this.
pal: Going back to IMSC 1.1, do we need fontVariant?
cyril: Netflix is not using it.
RESOLUTION: We do not need fontVariant for half vs full width
or superscript/subscript
Break for lunch
back after lunch
Nigel: Those present immediately after lunch: Andreas, Pierre,
Nigel, Cyril, Glenn
... and Chris
... For the first part of this afternoon we'll iterate through
those style attributes in IMSC1
... that are not in TTML1 and work out the disposition in
TTML2, then based on that
... work out whether to deprecate in IMSC 1.1 (if included in
TTML2) or keep (if not).
Should ebutts:linePadding be deprecated? #278
github: [75]https://github.com/w3c/imsc/issues/278
[75] https://github.com/w3c/imsc/issues/278
nigel: Technical issue here - if we have linePadding and
padding on span then how do we
... resolve the situation when both are specified and differ
from each other?
atai: Two options: 1) don't allow padding on span or 2) if you
use linePadding then you
... shall not use padding in that area where linePadding
applies, i.e. no padding on span.
nigel: Or you could have additive rules, or precedence rules
etc.
glenn: This is about semantic not syntax (referring to the
issue text)
... Right now TTML2 has no linePadding, just padding on blocks
and inlines, and there are
... well defined rules for applying those in CSS and XSL. There
are no implementation issues
... there as far as I know.
nigel: I don't think we've demonstrated that we can map
linePadding semantic to TTML2 syntax.
... Specifically I'm not sure we have lineAreaBreak right yet.
... For example when there are nested spans with different
background colours.
... Given that linePadding is syntactically simple and no more
semantically complex than
... lineAreaBreak + padding on span, and we may not need
padding on span, should we
... resolve this by bringing linePadding in instead of padding
on span and lineAreaBreak.
atai: linePadding is used widely so there's no need to replace
it.
cyril: Can we clarify the support for this in CSS?
pal: Left and right padding on span in CSS applies it to the
beginning and end of the span
... whereas linePadding applies it at the beginning and the end
of the line in the inline progression direction.
... That's each line based on whatever the background colour is
at the beginning or end of that line.
glenn: CSS tried to define some break behaviour, clone or
slice, but that turned out not to
... be exactly what we wanted - clone ended up cloning each
nested background colour,
... repeating the nesting level. Secondly it didn't take the
colour of the last character on the
... line, which was kind of the same thing. We defined
inlineAreaBreak which gave us the
... ability to do cloning but only use the most nested.
nigel: When I went through all the permutations I didn't find
one that worked for all the
... cases.
pal: There's a semantic mismatch between the two models.
nigel: It occurred to me that in CSS it would be useful to have
an ::each-line selector as well
... as the existing ::first-line selector.
pal: Lots of other people have run up against this too.
cyril: Let's assume that when we talk to CSS they support
::nth-line, then that would be
... something we might target for use in e.g. TTML3. Now what
are our choices. An option
... that was kind of agreed was to have ebutts:linePadding in
IMSC 1.1 and deprecate it for
... the equivalent feature in TTML2 if there were one.
... Another option is to adopt ebutts:linePadding in TTML2
either with or instead of the existing padding.
... The options are to leave it in IMSC 1.1 or put it in TTML2
in replacement or not of the
... other padding feature. Are those the options?
group: [yes]
glenn: Some details on that. I'm assuming if we put it in TTML2
we would use a TTML2 namespace.
... Certainly tts:linePadding is no more complex than adding
inlineAreaBreak, if you're going
... to add one anyway. And if we do that then should we add
padding on content elements
... at all in TTML2, which we decided to do long ago.
atai: I opened the issue 5 years or so ago before we found the
solution of linePadding.
... In EBU-TT we allowed padding on span, and then found that
it was not actually a good
... solution. So EBU-TT-D deprecated padding on content
elements and defined linePadding.
... Therefore from this motivation there is no longer a
requirement for padding on content
... elements.
glenn: I understand Pierre's argument about complexity. My
feeling is that its possible to
... include tts:linePadding and I have no serious objection to
that. I agreed to fillLineGap on
... the same principle. Then the next question is do we keep
content level padding in TTML2,
... and if we do then we have to define the priority for both
being present. I would assume
... that the linePadding model should at least facilitate doing
it in the future even if we don't
... do it now, otherwise we will need to do it in the future.
My preference is to keep linePadding
... and padding.
nigel: My proposal if we wanted both is that the padding would
be additive.
glenn: Yes, that matches existing behaviour for padding on
block areas and inline areas.
atai: We need to discuss the namespace. Which namespace should
linePadding have in TTML2?
... Secondly, my impression is that every unused feature, with
no clear use case, adds more
... complication for implementers so it is better to take it
out than to include it, but I will
... not argue on this.
RESOLUTION: Adopt linePadding in TTML2, remove inlineAreaBreak,
keep padding on content
atai: I think the element in TTML2 should be as defined in
EBU-TT and IMSC1, with the
... ebutts namespace. If we change that then all the current
implementations will not work,
... and implementations have to be changed to support the new
version, and the reason is
... trivial.
flick: +1 it is trivial.
pal: When we imported it into IMSC1 we kept the ebutts
namespace. The advantage of keeping
... the namespace is that EBU-TT can reference TTML2 and we can
have one spec for this
... worldwide.
glenn: There's no precedent for this in TTML, and EBU owns that
namespace. If EBU
... decided to give it new semantics tomorrow then they would
be applicable here. THis
... makes our spec non-fixed by bringing in external
vocabulary. I'm fine with having
... IMSC import from non-W3C namespaces, it's been a consistent
principle in TTML to have
... everything self-contained. Although we include xml: and
xlink at least they are W3C
... defined core technologies. So I'm opposed to bringing in
other namespaces - it will
... complicate the spec and implementations. It is dangerous
for authors because it gives
... them the false sense of security that they can keep it the
same and it will keep working.
cyril: Clarify please?
glenn: Authors may think there are no changes semantically, but
there may be knock-on
... effects because it is happening in a different context.
... One more comment - there is a lot of code for
implementations and a lot of places in
... the spec that are keyed to using a TTML namespace and
keeping all the style attributes
... in the TTML style namespace. It would require a lot of
processing to introduce a new
... namespace.
atai: First we should not worry too much about the pure
philosophy of namespaces because
... we are continually defining new ones anyway - EBU-TT, IMSC
etc. For example if we in
... EBU-TT define a style element allowing style attributes not
allowed in TTML then we change
... the content model and therefore change the element.
Formally it's a completely new element.
nigel: You mean like allowing padding on span?
atai: That's one example, or if we disallow an attribute on a
TTML element, then we have
... defined a new element.
... There is no longer only one definition of each element.
cyril: I disagree with this.
glenn: I disagree too - we anticipated subset implementations
in TTML1.
... It is true though that W3C owns the namespace and would
likely not have allowed
... EBU to add things into the TTML namespace.
... Bringing in vocabulary from profiles breaks the Directed
Acyclic Graph of specifications
... and creates huge problems and is unnecessary.
cyril: Two points:
... It could be problematic if the ebutts: namespace were in
the TTML spec - if EBU defines
... a new feature in that namespace then people would have to
know which spec to look
... in for the definition. The second point is about
implementation - what are we talking about?
... Mostly adding Japanese - European TVs likely would not have
to change. The only
... ones are current IMSC 1.0.1 implementations in Japan, which
have to be augmented
... anyway. I'm not saying the change is free, but that it is
small, it is only a matter of namespace.
... You just have to do an alias in your implementation. The
pros are the spec simplicity and
... visibility (only one place to look) and in the future
setting a precedent for everything being
... in the TTML spec, not having everything together.
pal: Two things:
... EBU would have to be involved to move linePadding,
fillLineGap etc so they can remove
... them from their spec and ultimately create a pure subset of
TTML2.
... If EBU says no then that solves that problem, we can't do
it. Importing it would remove
... the risk of cyclic references and the idea of EBU removing
it from their namespace.
... The second thing is that alerting people to changes in
semantics is exactly what we
... don't want to do, introduce differences in semantics!
... On the issue that it is a minor change, it is a change.
Every new feature is a new set of
... tests, bugs potentially etc and I don't see anyone paying
for it. Who is going to be motivated to do that?
... Who is going to train all the EBU-TT-D authors?
... Assuming EBU wants to play along I don't see a compelling
reason here.
glenn: Were you assuming that if we work with EBU and bring
this in that we would bring
... it into a tts namespace or that we would somehow own
something in their vocabulary?
pal: That we would own the element in the existing vocabulary.
glenn: But EBU owns that namespace, period.
pal: They can choose to relinquish or delegate it to W3C, this
happens often.
atai: For the namespace domain thing there is no such rule for
linking a name to an authority.
... It is a common assumption but the namespace could have any
string that you want. It is
... not really something we need to worry about too much.
... Cyril, the impact of changing the namespace on
manufacturers could be that current
... documents may not work on new implementations if they don't
implement both.
nigel: Simple pattern for dealing with that in IMSC 1.1 to
deprecate ebutts:linePadding and
... set precedence rule if both are present.
atai: Second point is that we are assuming some future change
in CSS so that's an argument
... for using the current terminology and later doing something
more CSS/HTML conformant.
glenn: Propose a compromise I could live with:
... Pre-deprecate, i.e. define linePadding in tts namespace and
for compatibility allow it to
... be used as an alias for compatibility and refer to
ebutts:linePadding as an alias for the
... new tts:linePadding, and deprecate ebutts:linePadding.
atai: What is the difference, you also take the authority of
the TTWG and redefine the meaning
... of ebutts:linePadding. You're saying if you encounter
ebutts:linePadding then map it to
... tts:linePadding. I see no difference.
... This would depend on EBU being willing for this to happen.
... It would be cleaner to move it in completely.
glenn: It would break the rule of everything being defined in
TTML namespace.
pal: There's no shame in recognising that EBU did a good thing
and making it available more widely.
glenn: We've been following some principles for a long time
that this would break.
pal: That principle seems really restrictive.
glenn: I would probably have this argument even if it came from
a W3C spec, probably.
pal: The point is that by changing it you make it rougher round
the edges for everyone.
nigel: Doesn't this proposal work for all the constituents,
implementers, users, specifiers?
pal: Not for implementers, they have to introduce aliasing in
their implementations.
glenn: It doesn't take extra work to add aliases.
pal: It does make a difference for implementers though.
atai: Another compromise I've mentioned before is to leave out
the linePadding feature
... altogether and keep it in IMSC.
nigel: Then IMSC 1.1 is not a pure subset of TTML2.
atai: Correct.
glenn: The compromise I suggested would both allow the subset
and be implementable.
... I could leave with the compromise of leaving it out of
TTML2 also. The amount of work
... is trivial to introduce the alias.
... One plus about my approach is it gives a path for EBU to
get the extensions they've
... made migrated into a W3C blessed specification that they
might feel useful and may
... provide an opportunity for more cooperation.
... I feel it is a detraction to omit it from TTML2 because it
removes a useful feature for use
... globally.
nigel: Observe that there was actually formal consensus for
omitting ebutts:linePadding from TTML2
... and keeping it in IMSC 1.1
cyril: I need to check Netflix position on this.
glenn: I've heard David Ronca say IMSC vNext should be a subset
of TTML2 and prefers
... it all to be in the TTML namespace.
nigel: The position we have reached is to remove
inlineAreaBreak from TTML2 and not add
... linePadding in.
pal: I would go back to the IMSC vNext requirements and
specifically exclude those features
... that are not in TTML2 today.
... To make it obvious. If we had decided to import them into
TTML2 we could have kept
... them the same, but at this point today these are the
exceptions we have.
Should ebutts:multiRowAlign be deprecated? #277
github: [76]https://github.com/w3c/imsc/issues/277
[76] https://github.com/w3c/imsc/issues/277
nigel: The idea here is that the TTML2 semantics of setting
textAlign on nested elements
... does the same thing as multiRowAlign and therefore we no
longer need multiRowAlign.
... But the mapping to CSS doesn't work.
glenn: Elika suggested using display:inline-block
cyril: CSS would like to understand the use cases and
constraints rather than receiving a solution.
pal: That would be the multiRowAlign case.
glenn: I think there is no meaning of alignment in span in CSS
because there's no extra
... space, unless you set width explicitly.
pal: display:inline-block only works in CSS if you have
explicit line breaks.
... A question for CSS is if that is a bug in browsers or by
design.
... If they say it is by design then we can ask how to proceed.
glenn: I looked at this before and concluded that the spec
doesn't support the browser
... implementations.
cyril: Can we do it in two steps? Do we agree the semantics of
multiRowAlign need to be in
... TTML2?
pal: This is in use
glenn: It is defined in TTML2 and implemented in at least one
implementation.
cyril: Is this a case where it is defined in TTML2 with a
different syntax.
glenn: It requires more content work to do this in TTML2
because you have to create
... nested spans and setting inline-block. There's a
transcoding issue but no namespace issue.
cyril: So there is a way to do it. Does this fall into the
category we agreed before in the
... deprecation model?
pal: I think it falls into the same category as linePadding
that we just did.
... It would be a stronger argument if there were a direct
mapping to CSS.
... The approach in TTML2 has a different syntax from what is
in wide use in IMSC1.
glenn: And there's a question about mapping into CSS anyway.
nigel: And the TTML2 syntax is more verbose.
glenn: A useful side effect of inline block is to create
horizontal and vertical struts, by
... setting ipd and bpd on inline blocks.
nigel: Can you set ipd and bpd to use all the available space?
glenn: Yes you can use allocation to use as much space as
possible.
atai: I agree for authors this is more complex. Is it more
complex for implementations too?
... For presentation processors it is more complex.
pal: For sure.
atai: I possibly would vote the same way as for linePadding but
for a different reason, to
... exclude from TTML2 and just include in IMSC 1.1. I am not
sure how often this feature
... is used in practice. multiRowAlign is widely used in legacy
contexts but only works because
... of the constraints of those legacy contexts.
pal: I would agree to keep this in IMSC 1.1 and ask CSS how to
do this.
glenn: It took 70 lines of code to implement multiRowAlign in
TTX, which translates
... it into textAlign in TTML2 with inline block. That's fully
tested.
nigel: So you would not deprecate multiRowAlign even though it
can be done in TTML2?
atai: correct
pal: It is extra work, and if we think it may not be used, then
we should not use it.
... I would not allow inline-block in IMSC 1.1
nigel: Is inline block needed anywhere else?
glenn: There are edge cases that need inline blocks using
struts.
nigel: What are those cases? Do we expect them to be used?
glenn: I have to check but I believe I am using it for
rubyReserve.
nigel: So you're mapping one TTML2 syntax to another?
glenn: Right
nigel: So there's no authorial requirement to use inline
blocks?
glenn: Correct. The requirement came from SMPTE digital cinema
to specify a varying
... width, which can only be done with ipd.
pal: Digital Cinema isn't driving the requirement for IMSC
RESOLUTION: Do not deprecate ebutts:multiRowAlign, prohibit
inline block, leave TTML2 as is.
Break
Add parameters to define the temporal extent #483
github: [77]https://github.com/w3c/ttml2/issues/483
[77] https://github.com/w3c/ttml2/issues/483
glenn: If I parse a document and find it only has a caption
from 1000 to 1001s then I can
... conclude that anything blank from 0s to 1000s is blank or
undefined from the perspective
... of that document.
nigel: You can't distinguish between a defined empty
presentation behaviour and no
... defined presentation, since there's no way to define an
empty presentation for a specific period.
... This is useful for segmentation or live delivery for
example.
glenn: It could impact the display of backgrounds when
showBackground="always"
group: [discusses use cases]
glenn: I have enough answers to be able to review this now.
... I had a use case for resolving indefinite duration -
clipEnd could be used for that.
... That was my intent for defining mediaDuration. I could see
that this could be independent
... of having a related media object.
nigel: yes
glenn: That's why I asked you to consider media duration, at
least for the end point.
Add ttm:mediaTimestamp (or equivalent) attribute #125
github: [78]https://github.com/w3c/ttml2/issues/125
[78] https://github.com/w3c/ttml2/issues/125
nigel: We had two objections to the presence of ttp:mediaOffset
but it remains in the
... specification. We need to resolve this before moving to CR.
glenn: It wasn't a recent unilateral decision. I'm not sure
when.
archaeologist: tracker issue 335 and 361, raised by Courtney
Kennedy and Glenn Adams respectively
pal: My objection still stands.
... This arose from a mistake. People try to reproduce a
timecode based workflow.
... That timecode may be 01:00:00 for the beginning, or
10:00:00, not realising that you
... don't have to do that in TTML and that it's wrong. What
goes in TTML is a time offset.
... It is not 1 hour from the start of the video.
... So the idea of negative time offsets, to offset all the
TTML files by -1 hour rather than
... rewriting the timestamps arises.
glenn: You're right that being able to specify mediaOffset was
intended to normalise
... documents that use that convention, for example documents
that begin at 10 hours
... and you think that's the media time, then putting that
offset in would reset it to zero.
pal: My point is that's bad and we shouldn't encourage it.
nigel: Mine is that it is actively dangerous.
pal: Right, they should use media timebase.
nigel: I also object because it has no practical effect - in
the case of smpte discontinuous
... then it does not even apply.
glenn: Even if we don't define this I want to do a better job
of defining the relationship
... between the root temporal extent and the media time.
atai: It could be metadata to say when the beginning timecode
of the related programme is.
nigel: The document interchange context like an MP4 wrapper
already defines this.
flick: Take 2 documents to wrap in an MP4 document. It should
not matter if each is zero based.
cyril: No the time begins at the beginning of the first sample.
pal: In Part 30 for TTML the media timeline begins at the
beginning of the track.
... In IMF it is the other way around.
... Each thing is independent and starts at zero in that case.
atai: So the zero sync point is different in the related media.
glenn: So you partly want to encourage authoring content that
is zero based and can
... potentially be shifted around dependent on some external
relationship.
pal: When you author, you get some video content and you
position your events relative to
... zero being the first frame of the related video content.
glenn: In SMPTE continuous then 00:00:00:00 is the first frame,
right.
... For documents beginnins at 10:00:00 now you could support
that externally in the processing
... context if it has different information.
pal: Yes, for files I've seen they were wrong not only because
they begin at 10:00:00:00 but
... also they have the wrong frame rate.
glenn: I think we need to support taking advantage of external
media and if they want
... relative times for presentation that is not 10:00:00:00
that is not handled externally.
... We don't dictate authorial behaviour in profiles.
atai: It is not just a question of behaviour but also of
workflows.
... Pierre, this relation between time based media and the
related media time base. Do you
... think that the relationship between the time in the
document and the time in the media
... is completely defined by the interchange context or there's
no rule?
pal: Absolutely, I've seen lots of different examples.
nigel: One of my other objections is that DASH already has
PresentationTimeOffset, and
... I think this mediaOffset value will be extracted and copied
into that field and then
... wrongly applied twice, which is really dangerous.
cyril: +1
glenn: So in an interchange context that does not specify this
do we need to define this?
cyril: No
nigel: No
glenn: This came from TTML1 N.2: " If this assumption doesn't
hold, then an additional offset that accounts for the
difference may be introduced when computing media time M."
... When we wrote this into TTML1 we didn't go into this in a
great deal of detail at the time.
... It implies the existence of some offset and I viewed that
as a potential ambiguity in the spec
... that needs to be resolved in TTML2, which is why I defined
it. If we don't define it then
... we need to figure out what to do with that text in TTML1
and put something in TTML2
... that talks about the document processing context as needing
to resolve this issue.
atai: Can we resolve to remove ttp:mediaOffset as it stands and
as a separate issue add some guiding text?
glenn: Okay I can do that, as long as we try to resolve the
ambiguity. It will probably
... need a change in TTML1 Third Edition too.
RESOLUTION: Remove ttp:mediaOffset as it stands and open a new
issue to explain how to resolve media time
flick: Do mediaOffset and mediaDuration travel as a pair?
glenn: That was my intention
flick: Then we should remove that too.
glenn: I suppose clipEnd could fulfil the same purpose.
... I need to convince myself that the names clipBegin and
clipEnd are appropriate.
... So our basic assumption is that time zero is the beginning
of the document timeline?
pal: Yes, there is always an ISD that goes from zero to ...
nigel: I think the concept of an empty ISD should exist but I
think empty ISDs would get pruned by the current algorithms.
RESOLUTION: Remove ttp:mediaDuration
glenn: This has to be tied together with clipBegin and clipEnd
because we need a way to determine the end of the document.
... If you have a test process whose goal is to produce a set
of ISDs then unless you have a fixed
... duration that you can resolve that to you might end up with
different results in the case
... of showBackground="always" because there would be some ISD
from the last time to
... infinity that needs to be covered.
Back to IMSC 1.1 issues...
Should ittm:altText be deprecated? #274
github: [79]https://github.com/w3c/imsc/issues/274
[79] https://github.com/w3c/imsc/issues/274
nigel: First question: is altText application worth having a
named entity rather than using a generic one?
glenn: No, we made a decision on that before, we have the
generic ttm:item so we don't have to do that.
atai: Originally the idea of ttm:item was to pull in other
metadata defined by EBU and SMPTE
... and in EBU we debated it a lot and in the end decided that
the vocabulary is already defined
... and there was no reason to bring it to a more generic
syntax so it would be better to
... remove it from TTML2 and use what is already there. I think
this could be a similar
... situation where there is something already defined and
there would be the option to take
... ittm:altText as is, or even put it in ttm:altText. I had a
look and I think it would be much
... easier to define the element with a local name like altText
rather than put the semantics
... into an attribute which makes it much harder to process. It
is cleaner to define the
... element with a namespace and a name and that's what it
means.
glenn: We defined an external registry and put it in the wiki
so that all those SMPTE and
... EBU metadata could be defined by users and registered. We
created a naming mechanism
... so they could be made unique and avoid naming collisions
using URIs. We definitely
... did not decide to eliminate the element.
atai: We took out some of the named items from TTML2.
glenn: We had a whole list that were removed and went to the
trouble of defining a registry
... for that. Every time you add a new element it has an
overhead in additional ways for example
... in specification, testing, implementation, authoring
knowledge. The HTML meta element
... has been serving for many years as a generic tool for
expressing metadata and this
... basically follows that.
nigel: We need to move from the general to the specific here
and consider this specific use case.
atai: My argument is to move it to TTML2 as ittm:altText or if
not then ttm:altText.
glenn: There is no technical reason, so the only reason could
be preference.
pal: People are used to altText and now they have to go looking
somewhere else.
nigel: It is easier to hang normative language off a defined
entity and also to validate
... documents based on it.
glenn: I agree that it's cumbersome to create generic elements
just for this purpose. I could
... live with adding a ttm:alt attribute which would be
available on almost any element
... including tt:image.
pal: would it be applicable to other things?
glenn: Yes, the spec doesn't mandate use of any metadata.
pal: Could you store a metadata element under the image
element?
glenn: Yes you could have a metadata element as a child of
image
pal: What if someone puts both ittm:altText as a child element
of image and alt attribtue
... on image.
glenn: Since TTML doesn't know anything about ittm:altText then
it could be pruned.
pal: IMSC 1 would only deprecate ittm:altText. If both appears
which one should...
glenn: TTML2 would only know about ttm:alt and besides it
doesn't define any behaviour
... associated with metadata. It is only for authorial
purposes. An application could make
... use of it for accessibility purposes like in browsers but
that would be outside the scope
... of TTML to define what that is.
pal: Would there be a new feature designator for it?
atai: There are not feature designators for metadata attributes
now. So you do not need
... one. Why would you? Just use the feature #metadata.
glenn: Actually there is a feature designator #metadata that
covers all the metadata vocabulary
pal: That's already allowed in IMSC
glenn: We should add a v2 designator including ttm:alt
... Can this cover backgroundImage? It can because
backgroundImage takes a reference
... to an image resource, as a fragment identifier referring to
an image element, which
... itself could have a ttm:alt on it and therefore the
background image could be associated
... indirectly.
pal: You might put the alt on the element with the
backgroundImage itself, presumably.
RESOLUTION: Add ttm:alt attribute to TTML2 and permit it in
IMSC 1.1 and deprecate ittm:altText in IMSC 1.1
pal: Wording for ttm:alt should match ittm:altText now because
we spent a lot of time on
... that so let's not blow it by changing that. Copy as is
please.
Should itts:forcedDisplay be deprecated? #279
github: [80]https://github.com/w3c/imsc/issues/279
[80] https://github.com/w3c/imsc/issues/279
nigel: Works through the example in w3c/ttml2#482.
... Pierre, you think that's too cumbersome.
pal: Maybe in the future we will find a use for condition in
IMSC but we have not got
... enough interest to include it. Instead, put
itts:forcedDisplay into TTML2 or just leave it
... in IMSC 1.1 and not deprecate it, and make it an exception
to that subset requirement
... [imsc1.1 being a subset of ttml2]
glenn: It can be implemented by translating to the condition
mechanism for presentation.
... That's what TTPE does.
... If this was the only argument for condition I would agree
to make a specific
... attribute for it in TTML2.
pal: Notice that forcedDisplay is not purely a presentation, it
also carries some semantic
... meaning, something that you can't easily backtrack from
condition expressions. When you
... talk about forced subtitles it means something in industry.
flick: And they want to preserve the forcedness without using
more complex vocabulary.
pal: Yes these are subtitles that are designed to be shown to
all viewers regardless of
... whether they have opted to display e.g. hard of hearing
subtitles.
... So there's an argument for having an explicit forcedDisplay
attribute in TTML2 because
... of that meaning.
glenn: We did add a named metadata item called usesForced to
signal that the document
... uses forced.
atai: Forced is established, has been implemented, and it is
easy to discover if it has been
... applied, so the current solution in IMSC satisfies that
requirement. For me it is as before
... in previous conversations, it is best to leave it in IMSC
and not redefine it in TTML2 but
... continue with the established practice.
glenn: You should add this to your list of non-subset items.
nigel: We seem to have consensus to keep itts:forced and not
add anything to TTML2
... We could add an informative note to say that it can be
implemented by a TTML2 processor
... that supports condition using an example like the one in
w3c/ttml2#482.
pal: I wouldn't object to that.
RESOLUTION: Keep itts:forcedDisplay in IMSC 1.1 and do not add
anything to TTML2
Should itts:fillLineGap be deprecated? #276
github: [81]https://github.com/w3c/imsc/issues/276
[81] https://github.com/w3c/imsc/issues/276
atai: My proposal is to do the same as linePadding, to leave it
in IMSC 1.1 and take it out
... of TTML2. The rationale is first that we are waiting for a
proper solution in HTML and CSS.
... It won't happen before we publish TTML2 so we should keep
the established solution.
... From the previous discussion it is unlikely that we will be
able to pull it into TTML2,
... or define it in a new namespace, so we should take it out
of TTML2 and keep it in IMSC1.1.
glenn: Does Netflix plan to use fillLineGap?
cyril: We are not using it now but I think we want to use it.
glenn: I have no objection to taking it out but we should get a
Netflix view.
... There was a question about if it is semantically the same.
pal: It was different. We spent a long time getting it right in
IMSC 1.1 so we should copy
... it directly.
RESOLUTION: Remove fillLineGap from TTML2 and retain
itts:fillLineGap in IMSC 1.1.
ttp:displayAspectRatio is prohibited #273
github: [82]https://github.com/w3c/imsc/issues/273
[82] https://github.com/w3c/imsc/issues/273
nigel: Why don't we adopt ttp:displayAspectRatio and keep the
SHALL note about
... centering the root container region that is in IMSC 1.1
glenn: They're not equivalent, because you can specify
pixelAspectRatio in TTML2.
nigel: In the case that pixelAspectRatio is prohibited they
resolve to the same thing?
glenn: Maybe.
... This wasn't about spec purity but avoiding ambiguity in
TTML2.
pal: Adopting ttp:displayAspectRatio would be self-inflicted
pain and will lead to implementation
... pain and documents containing both ittp:aspectRatio and
ttp:displayAspectRatio for
... years to come.
nigel: It's an easier case though here to deprecate
ittp:aspectRatio and permit ttp:displayAspectRatio
... since they're semantically the same. Just set a precedence
order and define ittp:aspectRatio
... using the semantics of TTML2 by reference.
pal: We could keep ittp:aspectRatio and not deprecate it, but
state that it is the same as
... ttp:displayAspectRatio in TTML2.
atai: But you would not remove ttp:displayAspectRatio from
TTML2
pal: No.
... The use case is for 4:3 centre cuts of 16:9. For
progressivelyDecodable I have no usage information.
... Here I do not know how much it is used.
... I have seen IMSC documents with ittp:aspectRatio="4 3" so I
think it is used.
nigel: We already agreed a deprecation model for IMSC and TTML2
and this appears to be
... a case where we should apply that decision.
cyril: I think we should deprecate ittp:aspectRatio and add
ttp:displayAspectRatio
atai: There's another option to leave ittp:aspectRatio in IMSC
1 and don't change TTML2
pal: There's a one to one mapping between the two.
nigel: So you would keep ittp:aspectRatio and add an
informative note that it is the same
... as ttp:displayAspectRatio or provide a mapping?
atai: I would be in favour of that.
glenn: Would you more generally provide the mappings to TTML2?
pal: Yes why not.
cyril: Now we have diverged from IMSC 1.1 being a subset of
TTML2 I can't express a view.
pal: There was an absolute objection to bringing IMSC 1.0.1
syntax into TTML2.
... That's why we are revisiting this.
atai: It is a practical compromise that we are looking for.
glenn: Raising a point about deprecation, we had one
deprecation in TTML2 for a TTML1
... feature, which was the use attribute on an extension or
feature and Mike objected to
... having any deprecations of TTML1.
nigel: I think we persuaded him in the end that we weren't
prohibiting it and it was okay.
RESOLUTION: Retain ittp:aspectRatio in IMSC 1.1 and add a note
explaining the equivalence to ttp:displayAspectRatio in TTML2
Meeting close
nigel: Thanks everyone, a very productive day! [adjourns
meeting]
... I realised I didn't record one of the later resolutions
that modified a previous one,
... about linePadding, which we agreed to remove from TTML2.
RESOLUTION: Remove linePadding from TTML2
trackbot, start meeting
<trackbot> Meeting: Timed Text Working Group Teleconference
<trackbot> Date: 10 November 2017
Introductions
nigel: People who were also here yesterday
[83]minutes from yesterday
[83] https://www.w3.org/2017/11/09-tt-minutes.html
nigel: Cyril, Eric, Chris, Andreas, Pierre, Nigel, Thierry
<scribe> scribe: nigel
<scribe> Chair: Nigel
This meeting
cyril: Can we spend 15 minutes preparing for the CSS joint
meeting?
... Also putting tests on web platform tests.
nigel: OK, let's do that.
CSS meeting prep
cyril: 3 buckets of things to discuss:
... 1. Japanese language requirements -
<pal> rubyAlign
<pal> rubyOverflow
<pal> rubyOverhang
<pal> textOrientation
<pal> fontShear
<pal> rubyOffset
<pal> rubyOverhangClass
<pal> rubyReserve
cyril: These are things in the white paper.
... 2. Line related styling - fillLineGap, linePadding,
multiRowAlign.
... and I'd like a common understanding of how ruby annotation
behaves in terms of lines
... and line stacking.
pal: Another one to deal with is spurious spaces before <br>
which I think is a bug in Chrome
... but it does not match the CSS spec, which leads to extra
padding in the end.
... It is a known bug but we should remind them of the impact
it has on subtitles.
cyril: 3. All the other properties for which mapping is not
correct.
pal: Top of that list for me is textOutline. At some point
there was a proposal to deprecate
... textOutline because it was not supported by browsers (it is
supported only by Webkit).
... textShadow is not equivalent and not the style of subtitles
that everyone is used to for movies for example.
Nigel: It would be good to check they have the information they
need. They want to know
... what the desired outcomes are so I want to know if they
have that.
flick: We need to establish a process for completing this in
association with the CSS WG
atai: We have a limited time with them
nigel: 1 hour I think
atai: It would be good to discuss if we could join a CSS WG
meeting even if we are not a part of it.
ericc: If you want to make sure it gets done someone needs to
pay attention to it.
pal: I am a member of CSS WG and I can contribute.
... We should ask how we can make sure these issues turn up on
the agenda.
cyril: We should make sure they are aware that in principle we
would like to use these in TTML.next
pal: It is more general - the functionality should be in CSS,
it might be used elsewhere, WebVTT or other places.
ericc: Captions are an important part of the web platform, so
if these are important for
... the display of captions that is the use case and we don't
need to go further than that.
nigel: Conclusion is we need to explain this is important and
that we want to work together
... with them to get it done.
Web platform tests
cyril: The first step is to put the tests we have on the repo
without changing them.
atai: You can do that without integrating them?
cyril: Yes
atai: And the goal is to test them against polyfills?
cyril: The best way to do it would be to use imscJS as a
polyfill but polyfills are not
... integrated very well in web platform tests
... Pierre tells me that it's easy to get the HTML fragments so
we can use the rendering of
... those as the reftest, which takes out the differences
between rendering engines.
pal: Things like font smoothing can modify all the pixels so
this approach works better
... than comparing with the PNGs in the reftests.
frick: Presupposing that a browser will have implemented TTML
may be a difficult.
pal: That's the direction that things seem to be going at a
meta level, not to put things
... in the browser core if they can be done by a polyfill.
... Where the rubber meets the road as we discussed briefly is
user customisation.
... Unless there's a specific reason for implementing natively,
like for example power consumption,
... then using a polyfill will be preferred.
... It's been a pragmatic process - don't implement in core
browser unless ... (I could be wrong)
... All other things being equal it would be nice to have it in
the browser.
atai: In a sense imscJS is not a polyfill to fill a gap in some
browsers but more a bridge.
pal: A question: I think it is better if implemented in the
browser but I don't think it's necessary. I'm testing that
statement.
frick: Better from some perspectives but worse from others.
pal: Yes, harder to make changes, more support needed.
ericc: Implementing it could take resources. The Wednesday
session is really important to
... follow up on because there's a disconnect right now about
honouring the user's captioning
... preferences which is not possible with a polyfill.
... I think the answer is to define and add an API to HTML so a
library can add generic
... cues to a track with enough information for the browser to
be able to render it in the way
... that it was authored. Not to add another specific interface
for a particular format but a
... generic interface.
pal: How can that not be the full set of IMSC 1.1 features?
ericc: Just exploring this out loud - if it is possible to
render to HTML and CSS in a library
... then it should be possible to give the browser enough
information to do the same thing.
... Maybe the interface makes a document fragment and gives it
to the browser.
pal: With specific styles.
atai: It's really interesting to think about the details.
frick: To connect Pierre's touch points with what Eric was
saying, I'm interpreting it as that
... these cues provide the background for the timing but the
expression of details of how
... it renders is a combination of the HTML and sufficient CSS
to allow it to be styled.
ericc: And with enough information to allow the browser to
identify the parts that the
... user preferences want to override in terms of styles.
pal: Imagine the reverse approach - that the cue contains a DOM
fragment and the browser
... sets some specially named styles based on user preferences,
and those CSS styles are
... applied to the DOM fragment at the time of rendering.
ericc: That's what I am saying, BUT it has to become
unavailable to the generating code
... after styling [to prevent fingerprinting based on style
preferences].
pal: So the browser doesn't have to parse the DOM fragment,
just set the styles.
ericc: That's exactly what I'm saying. I don't think there's
anything in HTML that corresponds
... to this, so there may be unexpected issues with it.
nigel: As well as user preferences there are player styling
things like moving captions out
... of the way of controls.
ericc: We may not be able to do everything here.
atai: We have to be able to provide enough knobs to control the
presentation.
nigel: The thing providing the DOM fragments can make
adjustments to those DOM fragments
... that they provide.
ericc: I don't think all CSS will necessarily be supported.
frick: 3 parts of the continuum: full browser support,
intermediate support, polyfill only
... Moving along this continuum will take time, maybe starting
with the polyfill and then
... eventually moving up to full browser support.
pal: All three are viable.
frick: The polyfill can prove this across all browsers.
cyril: Back to the testing discussion...
atai: The idea of bringing our imsc tests to the web platform
test suite is a really good one
... to show that we have a positive approach together with our
request to be more strongly
... integrated with the web platform.
nigel: I think we're all agreed - I don't think there's an easy
way to bring imsc-tests repo
... contents in by reference to the web-platform-tests repo
atai: I think Philip Jagenstadt mentioned something about this.
frick: That could be a follow on conversation.
Should ittp:activeArea be deprecated? #275
github: [84]https://github.com/w3c/imsc/issues/275
[84] https://github.com/w3c/imsc/issues/275
<tmichel> Tool planning specification milestones.
<tmichel> [85]https://w3c.github.io/spec-releases/milestones/
[85] https://w3c.github.io/spec-releases/milestones/
nigel: There's already an issue on TTML2 (not sure which one)
to modify the syntax
... to take position extent rather than origin extent
atai: Similarly to yesterday we have options:
... 1. Deprecate ittp:aspectArea in 1.1 and use ttp:activeArea
from TTML2
... 2. Not deprecate ittp:activeArea, leaving as in 1.0.1 and
take out ttp:activeArea from TTML2
... 3. Keep both and specify the mapping in IMSC 1.1 to
ttp:activeArea
pal: Deprecating something that has just been added to IMSC
would not make sense.
atai: I would support that, for example it has recently been
adopted by DVB for implementing
... by hardware manufacturers for TVs - if they see that it is
already deprecated that's not
... a good sign.
frick: It doesn't encourage trust.
glenn: What did ATSC do?
pal: I don't know.
... I looked, there's no mention of it.
nigel: This could be a good example where we informatively add
the mapping to TTML2
glenn: Yes
pal: I would not have any problem with that.
atai: In this case the mapping is 1:1 though
pal: It is bizarre
... Same argument as yesterday - pragmatic approach would be to
import ittp:activeArea
... into TTML2 as is, so it can be referenced by everybody.
... Having these two present is going to be confusing to
implementers and is not doing a
... service to the industry.
nigel: Check that the objection to bringing in ittp:activeArea
to TTML2 still stands?
glenn: Correct.
cyril: I need to confirm.
atai: Is there any objection to removing ttp:activeArea from
TTML2?
glenn: Yes I want to keep it in.
atai: I made the wide review comment on the TTML2 issue that it
should be the same as in
... IMSC 1.0.1 including namespace.
glenn: Agree to change TTML2 syntax so that the IMSC 1.0.1
syntax is conformant with it.
nigel: The consistent way to do this in TTML2 is to change
origin to <position>.
pal: Why impose a change on implementors compared to what is
there now?
nigel: Bigger context - the TTML2 spec is more general and
broader. If an implementer has
... generic position processing code for CSS positions, then
it's arguably perverse to limit it.
... Propose: keep ittp:activeArea in IMSC 1.1, modify TTML2
ttp:activeArea to take position instead of origin,
informatively note value mapping from ittp:activeArea to
ttp:activeArea
atai: I'd add if we do the informative mapping, then note that
the TTML2 feature is more
... expressive and therefore slightly different, to limit
confusion.
RESOLUTION: keep ittp:activeArea in IMSC 1.1, modify TTML2
ttp:activeArea to take position instead of origin,
informatively note value mapping from ittp:activeArea to
ttp:activeArea
Deprecation of smpte:backgroundImage in favor of tt:image #259
github: [86]https://github.com/w3c/imsc/issues/259
[86] https://github.com/w3c/imsc/issues/259
pal: My proposal is deprecate smpte:backgroundImage in favour
of TTML2 image
... In TTML2 image there has to be a mapping specified to
smpte:backgroundImage or an
... equivalence.
nigel: It can be in IMSC 1.1 can't it?
pal: Safe harbor is on SMPTE-TT so if we use image there has to
be an equivalence statement.
nigel: I need to check my notes on the call I had with SMPTE.
The conclusion was certainly
... that we will add a note about the mapping of
smpte:backgroundImage but I need to
... check if we need it in TTML2 or IMSC 1.1 or both.
glenn: We already agreed in w3c/ttml2#460 to add this note to
TTML2
RESOLUTION: Deprecate smpte:backgroundImage in IMSC 1.1 in
favour of TTML2 image
Should ittp:progressivelyDecodable be deprecated? #272
github: [87]https://github.com/w3c/imsc/issues/272
[87] https://github.com/w3c/imsc/issues/272
pal: This was introduced in Ultraviolet - I've reached out to
them and they've told me it is
... not useful or used and has impractical constraints such as
timing being prohibited on
... children of p elements, so it is not used and cannot be
used and we should deprecate it.
RESOLUTION: Deprecate ittp:progressivelyDecodable
pal: When we do that, I'm half tempted to omit the definition
in IMSC 1.1 and just reference
... the definition in IMSC 1.0.1
cyril: That's an editorial thing.
pal: Yes it's a style thing, it's what I'm thinking.
cyril: Makes sense.
atai: Makes sense.
RESOLUTION: Reference details of deprecated
ittp:progressivelyDecodable from source in IMSC 1.0.1
IMSC 1.1 issue wrap-up
Nigel: That's all the issues?
pal: yes
nigel: Does that mean that the blocked labels can be removed?
pal: yes I'll do that
CSS WG and TTWG joint meeting
nigel: Some quick introductions:
... Nigel Megitt, chair TTWG
pal: Pierre Lemieux, Movielabs
<cyril> Cyril Concolato, Netflix
<tmichel> Thierry Michel, W3C
<florian> Florian Rivoal, CSS-WG, Vivliostyle
<wdh> wdh: Bill Hofmann, Dolby Labs, observer
astearns: Alan Stearns, co-Chair CSS WG
<ericc> Eric Carlson, Apple
<Guest41> Chris Flick, Apple
<Guest41> nick /flick
fantasai: Elika Etemad, invited expert, editor of half the CSS
WG's specs
rossen: Co-chair of CSS WG, Microsoft
hober: Theresa O'Connor, Apple
nigel: High level picture is: how do we work together to get
the styling features needed
... for captions and subtitles into CSS where there are gaps?
florian: Not sure of the history here but it seems dangerous to
map from TTML to CSS
... because if there are differences in semantics then it will
be hard to identify.
... If the differences are subtle then it was not worth doing.
If they are big then it is bad
... because there isn't a mapping.
... We need to work with you to look at the use cases we have
and work out what is missing
... and add to CSS. From there we want to see is how you simply
invoke CSS rather than
... define something close and map it. As long as TTML keeps
defining something similar
... but not the same then we will have ongoing difficulties.
Maybe in TTML3 just describe
... the minimal CSS properties and define the layout. I don't
know how you get there but
... for the CSS side we need to work from use cases and look at
where it's not adequate
... and go from there.
pal: Emphasise that this is not about TTML, in terms of
requirements, it is about subtitles
... and captions, and it can be used for example in WebVTT. The
delta is for how we
... present subtitles and captions on the web.
glenn: Agree with Pierre to focus on the bigger picture.
... In 2003 we adopted a policy of using camel casing so any
CSS names we've taken have
... already changed so we can't back out of that.
fantasai: I don't think we care about that.
glenn: To the extent that we've pulled in CSS we've tried to do
it without changing semantics
... but there are some edge cases where we've clarified and had
to go beyond CSS. We want
... to minimise any differences. What florian said is true in
the ideal world but we have
... practical constraints too such as timing.
pal: This is not the topic today! The main question is about
gap filling.
nigel: I think there's recognition in TTWG that there may be
input we can provide.
florian: Concern about augmenting CSS - at some point it's
possible that CSS will add
... something and it won't work for TTML because it went a
different way.
atai: Can we move to concrete cases?
nigel: Cyril identified 3 buckets.
cyril: The first bucket is related to Japanese subtitling,
mostly described in the white paper
... I sent to the list.
... Second is line related properties, adding padding,
extending background, aligning lines,
... defining lines better in relation to rubys maybe.
... Third is those where a mapping isn't clear, maybe most
importantly textOutline.
nigel: In that bucket is a recognised issue about white space
handling at the ends of lines.
Japanese features
<fantasai>
[88]https://lists.w3.org/Archives/Public/www-style/2017Nov/att-
0006/Japanese_Subtitles_on_the_Netflix_Service.pdf
[88] https://lists.w3.org/Archives/Public/www-style/2017Nov/att-0006/Japanese_Subtitles_on_the_Netflix_Service.pdf
cyril: I sent the white paper to CSS.
... lists main features - boutens, rubies, slanted text.
... tate chu yoko
... We explain lambdaCap is not a standard, but we used it as
the basis.
... I did not send the CSS properties to the group, please
understand the context.
... fontShear - we use skewX() and skewY()
fantasai: You can fall back to oblique or synthesise it if
there are not obliques in the font.
cyril: What would be the angle?
fantasai: Undefined
cyril: David Singer also mentioned font variations, I don't
know how well they're supported.
... There is a slant axis.
fantasai: That would presumably be usable to solve this case.
florian: Do we slant the right way for vertical text? Oblique
doesn't do that, I don't know
... what slant would do.
cyril: For the TTML ruby properties, there are more TTML2
properties than we currently use at Netflix.
... tts:ruby is strictly equivalent to what is defined in CSS.
... tts:rubyAlign is slightly different - it defines two
additional keywords that TTWG is still
... discussing.
fantasai: It's worth - the Ruby spec's distribution approach is
partly based on justification
... opportunities that can be controlled by the text-justify
properties in CSS 3.
... auto means normally justify, or you can say inter-character
or spaces only, so you can
... achieve distribution of space you can do that, and control
if the spaces are on the outside
... or not through the ruby-align property.
cyril: tts:rubyPosition is very similar to the CSS property.
... At Neflix we think subtitles are better on fewer lines. For
two lines, the best choice is
... on top for the upper line and beneath for the lower line.
... auto takes care of not knowing where the line breaks will
be.
florian: This auto value doesn't generalise well to more than 2
lines.
cyril: The preferred behaviour is above all the lines but the
last one, and below for the
... last line.
florian: That variant is not easy, but if you wanted the other
way around, you could use
... the first line selector, but we don't have a last-line
selector.
pal: The point is not about hard or easy but the expectation of
what people expect to see.
florian: It is easy for two lines
cyril: You don't always control how many lines you get
astearns: In those cases, >2 lines, what does the "outside"
value do?
glenn: The first n-1 lines would be above, the last would be
below
astearns: That's what you want the auto to do?
cyril: Yes, the idea is to use "outside" instead of "auto",
which we have requested as the default
... for TTML2.
... Is "outside" supported?
fantasai: No but we can add it
astearns: Seems reasonable to add
hober: Seems reasonable
astearns: Best way to do this is to open an issue on CSS
explaining what you need and the
... use cases, and it would be useful info to say what usage
percentage.
cyril: I'll take the action to add that
pal: How does it get added to the agenda?
rossen: We scan the issues before meetings and add an agenda+
label
fantasai: For specs in active editing they will get triaged in
florian: For others you may need to push
hober: The Chair is your escalation path!
fantasai: Ask members to tag the issue with agenda+
... The Ruby spec is temporarily to one side while other things
are being worked on, but
... we can make it happen if there are things that are urgent.
cyril: Next one: rubyReserve is not yet ingested but we
consider it an important feature.
... It is the ability to reserve space where there are no
rubies to make sure that the line
... spacing stays consistent, we don't want the baselines to
jump up and down.
fantasai: Specify a big enough lineheight to deal with the ruby
rossen: That's one of the frequent proposals is to set
lineHeight >= 1.5em for Japanese so there is
... always enough space. Then you don't need anything else.
<astearns> suggestion in the CSS spec is in this section:
[89]https://drafts.csswg.org/css-ruby-1/#line-height
[89] https://drafts.csswg.org/css-ruby-1/#line-height
dbaron: The question is if there is a reliable way to do that
in a way that is not font dependent.
cyril: It is not clear to me how ruby contributes to line
height.
fantasai: Currently the content of the line is centered in the
line box in CSS and the ruby
... needs to borrow the bottom part of the line height from the
previous line, that will
... layout correctly as currently defined but if you put a
background on the line box then
... that will be an issue.
cyril: How do you apply a background to a ruby?
fantasai: Apply it separately to the ruby annotation
glenn: TTML2 has that now.
fantasai: Increase the padding-top by the height of the ruby to
increase the background area
... of the inline box.
pal: It's like fillLineGap
cyril: textCombine matches with text-combine-upright
... textEmphasis matches to three separate things in CSS.
... This paper doesn't mention rubyOffset, rubyOverflow
glenn: rubyOverflow deals with ruby being taller or wider than
the base characters so you
... have to introduce new space. For example if it is at a line
edge boundary and you have
... alignment constraints on the line do you let the overflow
go beyond the block boundary
... that contains the line, e.g. to the left, or do you bring
in the ruby and then push out the
... base characters by adding space after them. They are
discussed in the CSS ruby spec
... but it does not provide any control mechanisms.
fantasai: Earlier drafts of rubies had some controls, but it
was too advanced for level 1.
... We just said we would provide more controls for level 2.
glenn: This came up because we were trying to mimic a
particular implementation's behaviour
... that is commonly used for Japanese subtitle authoring. We
wanted to support the right
... thing and also the possibly wrong default behaviour in that
tool. It is too advanced for level 1.
fantasai: I suggest deferring the controls for that until
later.
glenn: There is only partial implemetnation in TTML2 so that
may be something we
... jettison before CR or mark as at risk.
cyril: In particular overhang, is ...
<fantasai> [90]https://drafts.csswg.org/css-ruby/#ruby-overhang
[90] https://drafts.csswg.org/css-ruby/#ruby-overhang
glenn: That's different, it's about deciding which classes of
characters can be overhung.
cyril: The basic overhang feature is not something we have
found but we want to investigate
... further so that may be something we push further out.
fantasai: There's a section on this in the CSS ruby spec, which
says what you can't do,
... but mostly leaves it to the UA.
... We don't have a really clear idea what we want to do and it
is more advanced and less
... critical. I recommend both of us leave it for the next
level.
cyril: writingMode - there's a difference in how it is
specified, to do with the inline
... progression direction.
fantasai: XSL-FO handled left to right columns in text was
pretty broken and I know you
... don't have content that depends on that so if you don't use
it then drop it.
pal: In CSS you have to control both writing mode and
direction.
... It seems to map to two things.
florian: This is one of the bad things about mapping
atai: TTML is 15 years old - at the time they began CSS wasn't
ready, and we have to deal
... with the solution as is.
plinss: Let's not revisit the past.
pal: We want to identify things that should be possible but
that are not possible. So far
... I have not found anything like that for writingMode.
fantasai: Do you have a direction property?
glenn: Yes, it's basically the same as in CSS
<fantasai>
[91]https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode
[91] https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode
fantasai: The writingMode mapping for SVG is as above. You will
get better results if you
... map according to this.
glenn: writingMode as specified was an additional parameter to
unicodeBidi. There's always
... the override or embed (no isolate at that time) bidi
context
... There was only one option to define the default bidi level,
so that's what direction does
... for a paragraph. Those are the only semantics right now.
fantasai: That's fine, it's what it should be.
... The writing-mode from 13 years ago was a shorthand that was
harmfully controlling
... both direction and writing mode. I guess nobody is using
writing mode for subtitles
... right now so that's not likely to be a problem.
... When we mapped to keywords I did not change the name of the
property so that we
... would force implementations to change
cyril: So writing mode only sets block progression direction
and direction only sets inline?
fantasai: Yes
<fantasai> s/ writing modes for subtitles on Hebrew or Arabic
on Hebrew / Arabic on Hebrew / Arabic/
glenn: right now in TTML writingMode sets an "uber default".
<inserted> Cyril: We can take an action to review that in TTML
then
dbaron: It's important that the direction property matches the
underlying text, and where
... the logic is that embeds directionality allows
implementations can work out the right way
... to display that regardless of block progression direction.
pal: So far I have not run into issues. Suggest moving on.
hober: Try the SVG mapping and let us know if you run into
problems.
cyril: That's about it for the first bucket.
Line based styling
<dbaron> slide showing
[92]https://codepen.io/palemieux/pen/vyzbqW
[92] https://codepen.io/palemieux/pen/vyzbqW
pal: ebutts:linePadding [shows slide]
<dbaron> (although what the slide shows looks different from
what I see in my browser)
pal: What you'd like is padding on beginning and end of each
line, makes it easier to read
<dbaron> showing [93]https://codepen.io/palemieux/pen/MEvVjp
[93] https://codepen.io/palemieux/pen/MEvVjp
pal: This is in widespread use in subtitling and captioning and
is not possible in CSS today.
fantasai: Really demonstrates we can't use the box model - the
padding is not just at the breaks.
... Here there is no fragmentation point, it is just the end of
the block. That proves it is not
... related to the breaking controls.
pal: When I played with this I noticed there is no control of
padding or styling of a line area
... after the break has happened.
nigel: These features are not layout affecting?
pal: No because padding reduces the line width available so can
move the breaks.
... fillLIneGap - style dependent, strong feelings both ways,
no way in CSS to guarantee
... that the entire line area is filled with background
astearns: It is undesirable to have differences in background
height on a line?
pal: exactly
... [shows examples from IMSC 1.0.1 spec]
[94]IMSC 1.0.1 fillLineGap spec with examples
[94] http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html#itts-fillLineGap
pal: ebutts:multiRowAlign - lay out all the lines, pick the
longest line, align that according
... to textAlign, but then align all the other lines
differently relative to that longest line.
rossen: Why can't you do this with a block with alignment?
fantasai: When you wrap with a block we don't shrink-wrap to
the content. We don't trim
... extra space because that requires another layout pass.
[95]codepen demonstrating this.
[95] https://codepen.io/palemieux/pen/bgoLzb
pal: [describes styling and the effect]
fantasai: We have the same problem for headings and it doesn't
show up so obviously
... right now because we don't have the balancing thing.
... Once you have the ability to balance the headings so the
lines are equal, there's no current
... way to get a box that wraps to that balance.
pal: Unless you put an explicit br
fantasai: Exactly. As long as the max content size is larger
than the containing block @ @
... We need to specify the need to shrink-wrap around the
wrapped text.
cyril: Is this intended behaviour?
fantasai: It is, there may have been implementations that did
shrink wrapping but its
... expensive.
glenn: We couldn't find spec language to support the
implementations.
astearns: It is not straightforward if you don't know CSS
layout backwards and forwards.
fantasai: There is a max-min formula that gives the result,
which doesn't do what we need.
glenn: The inline block is expanded to the full containing
block?
fantasai: Right. This is a problem we need to solve.
rossen: Is the intention to be able to support two different
alignments?
pal: yes
fantasai: To do that you have to be able to calculate the width
of the shrink-wrapped container
hober: Please file an issue
pal: Someone filed an issue for this, maybe dbaron
... Different UAs have different behaviours on spaces at the
ends of lines, which is really
... annoying.
<fantasai> [96]https://github.com/w3c/csswg-drafts/issues/191
<- shrinkwrap issue
[96] https://github.com/w3c/csswg-drafts/issues/191
dbaron: The CSS spec defines this but implementations don't do
things right.
pal: The CSS spec is clear that spaces at the ends of lines
should be surpressed - it is right
... in Firefox but not in Chrome. My read is the spec is clear,
which should be confirmed.
fantasai: [looks up spec]
pal: My read is the space should be suppressed.
<fantasai>
[97]https://www.w3.org/TR/css-text-3/#white-space-phase-2
[97] https://www.w3.org/TR/css-text-3/#white-space-phase-2
<fantasai> Step 3 : "A sequence of collapsible spaces at the
end of a line is removed. "
florian: I think so. In chrome there's a bigger thread on the
handling of this and we're
... trying to get it fixed.
fantasai: The spec is indeed clear
[98]codepen showing this issue
[98] https://codepen.io/palemieux/pen/PjeKyq
pal: The behaviour depends on whether the space is in a span or
not
... The last issue is textOutline
... textOutline is used on basically every single movie
subtitle.
fantasai: We used to have it in the text decoration spec and we
were asked to remove it.
... Now we have a dedicated property text shadow and also a
fill stroke module.
hober: This is controlling the stroke.
<fantasai> [99]https://drafts.fxtf.org/fill-stroke/
[99] https://drafts.fxtf.org/fill-stroke/
pal: The stroke model grows the stroke, partially filling
inside, you only want to expand on
... the outside.
<dbaron> SVG added
[100]https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute
/paint-order which could help here
[100] https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/paint-order
rossen: Isn't this the only feature that we pushed to level 4
of text?
fantasai: There was a spread radius idea
rossen: Text spread is exactly the requested feature, right?
fantasai: Depends what you want to do on sharp corners
<fantasai> old text-outline property -
[101]https://www.w3.org/TR/2011/WD-css3-text-20110412/#text-out
line
[101] https://www.w3.org/TR/2011/WD-css3-text-20110412/#text-outline
<pal> [102]https://codepen.io/palemieux/pen/ZJpwxJ
[102] https://codepen.io/palemieux/pen/ZJpwxJ
<fantasai> Rossen mentioned the spread radius argument for
text-shadow, which should probably be in the L4 draft
dbaron: Two solutions that could help, paint order or text
shadow spread
pal: text-shadow is useful but this is also useful
dbaron: paint order controls which of the fill or stroke paints
first
flick: We had some discussion - it depends on the colours being
fully opaque
fantasai: stroke-align would do this
pal: That's what we really want
<astearns> file an issue to fill out this section:
[103]https://drafts.csswg.org/css-text-decor-4/#intro
[103] https://drafts.csswg.org/css-text-decor-4/#intro
pal: For stereoscopic rendering, the use case is only for those
displays that are capable
... of stereoscopic presentation so you can decide how
important it is. The TTML method
... is very simple, just a disparity value - render and offset
the same image by some value.
... Don't do parallax or anything crazy like that, just render,
offset.
nigel: That matches broadcast TV standards.
pal: And every other standard out there.
... Is that something worth adding to CSS today? I'm happy to
file an issue. It's pretty
... straightforward.
... This is essential for subtitles or captions to be displayed
over stereoscopic video.
<fantasai> text-shadow with spread radius will be in text
decoration L4 (there's a placeholder in the draft atm, but I
should get that filled out in the next month or so)
pal: .. Otherwise it is not watchable.
fantasai: Is disparity inherited?
pal: It's on a region, so effectively like a div
dbaron: This is interesting because there are other pieces of
tech around and questions
... about how it interacts with 3D, VR etc.
pal: This is the minimal feature to avoid hurting brains of
viewers watching movies.
... It's compatible with CTA, SMPTE standards etc.
dbaron: We just have to make sure it's compatible with other
emerging things.
... We need to reach out to the right people.
fantasai: It would need to generate a stacking context.
pal: No you render individually to two planes, the left eye and
the right eye
fantasai: For CSS if you set this property on an element it
should set a stacking context
dbaron: File an issue and we should all pile on.
Wrap up, next steps
hober: Sounds like we have action items for every issue?
nigel: I think so.
cyril: Would be useful for Pierre to send those slides or push
them online
dbaron: Or put them in the minutes and send those.
fantasai: The TTWG had filed some issues on these before and
we'd asked about edge cases
... and we hadn't got clear responses but those slides really
help explain all the use cases.
nigel: Great!
fantasai: Now we understand much more clearly.
astearns: Those pictures and links to more would be very
helpful.
cyril: We have a way forward for the CSS properties, but the
rant is still there about syntax etc
florian: When CSS has all the properties then deal with that.
nigel: Yes, not in TTML2 but we're open to it in the future.
rossen: That was a very productive session for both groups.
nigel: I think so, yes. Thanks everyone.
Break for lunch
nigel: return at 1:30 please
TTML1 Third Edition
nigel: We need editorial effort to make progress and Pierre has
kindly offered,
... so as Chair I'm asking Pierre to become an Editor of TTML1.
pal: I'll try my best to maintain the tone and there will be
pull requests.
glenn: We can make it work.
pal: Any concerns?
glenn: None today
nigel: Thank you for that Pierre.
pal: I think I'm going to try to make a first pass and flag the
purely editorial things and make
... one big pull request and for the trickier ones make
individual pull requests.
glenn: One pull request for several issues? For the test suite
that would be a good case.
pal: There are a number of other informative items too.
glenn: Make your own judgement about grouping them.
... #224 and #225 can obviously go together (no begin times)
pal: There are some we may decide not to address, I don't know.
nigel: For backporting TTML2 fixes there's probably a diff you
can do.
pal: That's right.
cyril: This is good, many people helps reduce the load.
Timelines for transitioning our specs
glenn: I have a hard stop for TTML2 which is Rec by July 1. I'm
going to make a sprint
... starting mid-December through mid-January, focussing full
time on knocking off TTML2 issues.
... I hope to drive it to zero by mid-January.
cyril: That's good to hear.
glenn: If we can go to CR let's say by 1st Feb that would be a
goal I could sign up for.
... It will also depend on knocking off dependent TTML1 issues.
pal: That's pretty aggressive!
glenn: I agree, and I don't have a good track record for
meeting aggressive timescales.
pal: It's hard to do that without another face to face meeting.
nigel: Any constraints?
cyril: I have hard constraints, after Feb 1 I am not allowed to
leave the US
... Before that I am travelling to MPEG in Korea, 22nd-26th in
Jan.
pal: I'll be in Rio 28th-31st.
... Then in Geneva from 1st - 3rd
... Conceivably I could do Munich on 5th and 6th.
Cyril: I may be able to delay the travel restriction.
glenn: It'll be hard for me to do Feb.
nigel: Okay it's clear we have support for a f2f in Jan or Feb
we just need to agree the dates
flick: It's worth touching base with David Singer
cyril: So one option is 5-6 Feb in Europe.
glenn: Propose to block out 3 days to get all the issues fixed.
group: hard to justify 3 days, 2 days easier
glenn: if 5-6 I could make it ahead of time on Sunday 4th
nigel: And if not in Europe then in January in the US,
otherwise week of 8-12 in the US (probably west coast)
tmichel: It could also be hosted in Sofia-Antopolis.
cyril: Can we agree the dates on the call next week?
nigel: Yes I'll add it to the agenda.
<dsinger> 5-6 feb is 3GPP meeting for me Fukuoka
IMSC 1.0.1 timeline
nigel: We're in CR, awaiting a second implementation report.
[104]IMSC 1.0.1 Implementation Report
[104] https://www.w3.org/wiki/TimedText/IMSC1_0_1_Implementation_Report
cyril: Does TTPE support the two features?
glenn: We could probably add to those - I think I've got both
implemented, I'll check.
IMSC 1.1 timeline
pal: This should match TTML2
... Realistic to go to CR with IMSC 1.1 in early February
atai: I would like to see a timeline we are forced to follow
and we really have to meet that
... goal, and if something blocks then take measures to take
out features or whatever, so
... the schedule we lay out is a high priority requirement.
That's the hardest part of standards
... to really follow the roadmap.
glenn: This is much more achievable for getting to CR, since we
can't manage delivery of implementations
atai: TTML2 is an ongoing thing that covers a lot and we tried
often to have roadmaps
... and don't usually meet the milestones. I would suggest at
least for IMSC 1.1 where there's
... a specific set of features, which is more manageable, we
have a really strict timeline.
cyril: Can we go to CR for IMSC 1.1 before TTML2 is in CR?
wseltzer: Yes, as you go further forward you get harder and
harder questions. Going to PR
... you would want a more stable reference.
atai: That just moves the problem point further into the
future. If some features are not
... ready one option would be to mark the features as at risk.
cyril: That's one option or move to v.next
atai: I would decouple a bit IMSC 1.1 from TTML2 though it is a
good goal to tie them together.
... If TTML2 cannot bring in the required contributions we need
a plan, for example to leave
... out the feature.
nigel: If IMSC 1.1 depends on a TTML2 feature what would you
do?
<wseltzer> [[from
[105]https://www.w3.org/Guide/transitions2017?profile=CR&cr=new
Does this specification have any normative references to W3C
specifications that are not yet Candidate Recommendations?
Note: In general, documents do not advance to Recommendation
with normative references to W3C specifications that are not
yet Recommendations. See Normative References Guidelines. ]]
[105] https://www.w3.org/Guide/transitions2017?profile=CR&cr=new
atai: Maybe move the specification into IMSC 1.1
<wseltzer> [so it's a question the Director asks, but not a
straight blocker]
<wseltzer> [see also
[106]https://www.w3.org/2013/09/normative-references#whole]
[106] https://www.w3.org/2013/09/normative-references#whole
cyril: please no!
glenn: We don't identify features as at risk until we go to CR.
wseltzer: I don't know the specific details of the specs but
just added above references
... to the process about what the Director will ask.
... If there are reasons of the platform that make it likely
that referred things will be stable
... then that's a substitute for having reached recommendation
at the same time.
cyril: Responding to Glenn, we should distinguish the features
for which we think they
... are correctly specced but maybe not going to be implemented
from those where we think
... the current spec text needs further work.
nigel: +1
glenn: Quick point - right now TTML2 has all the normative
references pointing to final specs,
... there are no normative refs to non-final specs. There are
in the informative references.
... I plan to keep it that way.
nigel: We recently learned that it is allowed to normatively
reference CRs - I'm really uncomfortable with that.
wseltzer: I'm not encouraging it, the general policy is that
the state at least matches.
atai: To confirm it is possible to reference W3C specs not at
Rec if the Director agrees?
wseltzer: Yes. Gold standard is to reference Recs, but if you
can argue instead that there
... is specific reason to believe the piece you are referencing
is stable then the Director will listen to that argument.
dsinger: We've seen that in the past where we pick up stable
definitions from non-Rec specs,
... where those definitions are not at all contentious.
atai: Can we set a hard deadline for IMSC 1.1. If we are
setting a F2F meeting for Jan/Feb
... then it is unlikely to go to CR status in January.
pal: If we go to WR in 2 weeks then we have time for 2 months
review and to meet that timescale.
... To get the feature set that's really key and we're done
with requirements.
dsinger: The more gaps you leave the harder it is to document
wide review completion.
... It is easier to fix before asking for review.
pal: That's the goal, but if there's a goal for an informative
mapping from a TTML2
... feature to CSS it is not essential to put it in wide
review.
atai: End of Feb for IMSC 1.1 CR?
pal: If the WR ends before the beginning of Feb then at the F2F
you can deal with both
... IMSC 1.1 and TTML2 together.
nigel: So end of Feb for IMSC 1.1 CR works?
pal: Giving editing time after the F2F? Yes
glenn: I'd like to try to time it so TTML1 Third Edition get
published same day as TTML2.
pal: Yes.
glenn: If IMSC 1.1 is also available we might try to publish
all three at the same time.
atai: If possible yes
pal: Otherwise there'll be dependency issue.
Charter 2018
nigel: Our current charter expires end March 2018.
... So we need to think about what to do.
<wseltzer> [107]Current charter
[107] https://www.w3.org/2016/05/timed-text-charter.html
nigel: We have choices: 1. Extend - plh tells me he can extend
by 6 months.
... 2. Or make a new charter that would take us further out - 2
years?
wseltzer: That's a commonly used duration
... Wendy Seltzer, W3C Strategy Lead. I look at what's next,
and rechartering is a part of that,
... seeing what you might want to put into a new charter - here
to help.
<wseltzer> nigel: My view, we should recharter
<wseltzer> ... active group, making good progress on specs
<wseltzer> ... foresee need over the next 2 years to keep going
<wseltzer> ... multiple drivers: work isn't done; many liaisons
and external standards groups that reference this group's work
<wseltzer> ... regarding scope, think we should keep going with
TTML work
<wseltzer> ... complete semantics; still work to do with audio,
possible connections to WICG
<wseltzer> ... and text tracks
<wseltzer> atai: overhead of rechartering?
wseltzer: The AB has looked us generally to look for 5% members
supporting work, about
... 22 members, and that there are not formal objections. I
don't think we try to make that
... a hurdle if there is significant interest in the work,
that's of more concern than strict
... numbers. If there are participants and implementers then
the team will help make the
... case to the Director that you should continue. If on the
other hand there is limited
... interest then maybe W3C should reexamine and feedback from
members is part of the
... message back about if it is something the web needs.
dsinger: 5 things for the group that works on should think
about over the next few years.
... Text Track Cue work and DOM - incubation first is the right
answer.
... Synchronising what's on a page with behaviour, and
javascript, pre-flighting etc needs
... more thought, for exact time alignment.
... We're going to have to look at issues around navigable
video, VR, AR etc which are
... quite hard - where to put captions?!
nigel: Yes, BBC R&D has blogged on this
dsinger: There's CSS stuff too to meet captioning requirements.
... And if there's a need for more language support, there may
be more work to do there.
... As languages move from basic through to advanced, more work
will be needed.
... Those 5 are all things for the timed text community to look
at over the next few years.
nigel: +1
dsinger: And maintenance - the W3C shouldn't dissolve groups
that own standards that
... are complex enough to expect bug reports.
atai: I support all of those 5 things. And it helps if we
provide more test material
... for different languages. On text track and text track cue
and the WICG initiative, I would
... not yet make it a deliverable of TTWG yet because it is
dependent on other groups and
... participants. I would not give this group the
responsibility to find a solution for that.
nigel: I think the WICG work might come up with a
recommendation for deliverables that
... are a good fit for TTWG or for another group, it's too soon
to say.
... Recall that in Lisbon last year we resolved that if we
recharter and WebVTT is not in
... CR then we would not include it in the new charter.
... My understanding is that if a group stops working on a Rec
track document it gets published as a Note.
wseltzer: Yes you send it to Note.
RESOLUTION: We plan to recharter from 1st April 2018.
nigel: Any points about strategy and subject matter?
wseltzer: The questions are: Do you have the right people
participating?
... Do you need team help in getting participants engaged?
... Are there other people who are likely asking for things?
cyril: We could use more browser vendors in the group - very
happy to have Apple on board,
... but it would be great to have others.
nigel: +1
atai: I hope that the text track cue work will also generate
more interest in the work of this group.
cyril: CSS alignment should help too.
atai: Yes. It's hard just to ask for more browser vendors!
... CSS mapping, Text track and Text Track Cue initiative, and
Web Platform Tests are all
... things that could be a good sign.
<Zakim> wseltzer, you wanted to discuss WICG interaction
wseltzer: We've been hearing lots of interest from browser
implementers on incubating things
... in WICG and bringing to WGs when there's proof of
implementation, so good to hear
... that you're thinking about doing that. Another scoping
question: are there specific of
... those incubating ideas that we should be considering to
bring in, or making it easy to
... add to the charter when things get far enough through the
incubation process?
nigel: Can we do that?
wseltzer: It would need a review.
dsinger: So make an advanced warning that it could happen.
... I like doing things in CGs to start with because there's a
big difference in size between
... the people here and people at FOMS meetings.
atai: I would support that process, because you can start a
process with the option to fail,
... and also to discover what is the deliverable, but to
reintegrate into the group's charter
... is really good, more agile, if there's an easy way to do
that.
wseltzer: We did something similar in the Web Platform Group to
add some incubated
... deliverables and we scoped the review around only the
deltas.
... Members are always free to come to us to reexamine
something that's different.
... They also can do that without a charter review.
... It's good to give the group freedom to incubate. WebVR is
only a CG, but I agree they
... will have fascinating requirements, and that group or
elsewhere is a good place to start the conversation.
nigel: What's the timeline for getting to a Charter that begins
1st April?
wseltzer: 4 weeks AC review, 2 weeks resolving comments and
questions, plus the time
... before that for review in the W3M - at least two months.
dsinger: By the end of Jan we need it ready to start review.
[108]Charter repo for TTWG
[108] https://github.com/w3c/charter-timed-text
<wseltzer> [note also the generic charter template,
[109]https://w3c.github.io/charter-drafts/charter-template.html
]
[109] https://w3c.github.io/charter-drafts/charter-template.html
nigel: I'm happy to continue as Chair, or to have other
co-chairs, or if anyone would rather
... I step down, let me know!
<inserted> dsinger: We could do with a fresh co-Chair for you.
wseltzer: I'll add a link to the charter template, needs to be
compared to the charter
... draft that you have.
... It mentions the various horizontal review requirements,
testing good practices etc.
<dsinger> notes that the GitHub charter has an end date on
2016, and doesn't seem to match the current charter. suggest we
pull it up to date as a starting point
[110]Action for Thierry
[110] https://github.com/w3c/charter-timed-text/issues/1
nigel: Who edits it?
dsinger: The Chairs and the Team
nigel: Ok, works for me.
dsinger: I suggest the group chips in with GitHub issues
tmichel: I can start doing some cleanup on the first draft
dsinger: If we do that through the end of the year then during
Jan the Chairs and the Team
... should be able to do the polishing to send it out for
ballot.
TTML <--> WebVTT mapping
atai: The status remains as at TPAC in Lisbon. I checked with
the remaining editor,
... Loretta from Google, on that. It makes sense to revisit the
mapping document when
... WebVTT gets to CR status so there is a stable reference for
the mapping.
nigel: Is there any dependency on TTML2? Can the mapping be
done completely based on TTML1?
atai: Yes, I would keep it scoped to TTML1. I am not sure how
many people are using it.
... I would first wait on WebVTT getting to CR then check the
current document for any
... errors and then discuss how to proceed and what to do.
... I remain as Editor, and Loretta is the other contributing
member, since Courtney is no longer active.
dsinger: I haven't heard much about it - I think it is a fairly
quiet subject with no pressing need.
... A 608 mapping to TTML would be more useful. Is there one?
pal: Yes, SMPTE has them, RP2052-10 and RP2052-11.
... (for 708 too).
nigel: Does it need to be in the new charter?
tmichel: Otherwise you can't work on it
nigel: [surprise] I don't think we need to list Notes in the
charter to work on them.
wseltzer: As long as the subject matter is generally in scope
you don't have to name documents.
nigel: Isn't it obvious that a WG can go and revisit a Note
that it had previously published?
wseltzer: It would be possible for a Charter to specifically
exclude working on anything
... not in the deliverables.
... But that would not be usual.
ttp:version
pal: Can we get rid of ttp:version? Glenn have you been able to
consider it?
glenn: I'm assuming that it will remain.
pal: When can we come to a conclusion on that?
nigel: Do we have an objection to ttp:version in TTML2?
pal: There's an open issue
cyril: Can we add that to the agenda for next week's call?
nigel: Yes
glenn: I know it's coded and used.
cyril: Let's talk offline.
Break - return in 20 minutes
WebVTT
dsinger: We have 22 open issues, I would like to work through
any of them where we
... can help close them out.
... The first one is on colour, which has been open since first
WR
<dsinger> open issues here
<dsinger>
[111]https://github.com/w3c/webvtt/issues?q=is%3Aopen+is%3Aissu
e+label%3AWR-open
[111] https://github.com/w3c/webvtt/issues?q=is:open+is:issue+label:WR-open
dsinger: Tess has joined us for issue #365
... various attempts to solve since WR1
Wide Review Comment 2017: Text color must be mandatory #365
github: [112]https://github.com/w3c/webvtt/issues/365
[112] https://github.com/w3c/webvtt/issues/365
dsinger: I think we may have a proposal here, we have the right
people in the room.
hober: Summarising the hallway discussion - silvia if
acceptable to you, that's very exciting.
... The VTT spec should say UAs that do not support CSS and
wish to conform with VTT
... must support setting foreground and background color and
the bit I'm unclear on is
... do we refer to the 608/708 mapping doc by reference or make
the mapping in an appendix
... and do the specific class names defined require support in
a stylesheet in a UA that
... supports CSS. Not sure how much I care. We need some
RFC2119 language saying if
... you don't support CSS you have to support colour. THat's
what we agreed on.
<dsinger> 608 mapping here
[113]https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toV
TT/608toVTT.html
[113] https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html
atai: We agreed that they should support them as though at
least part of the stylesheet were loaded.
... I would prefer the mapping as an annex rather than
referencing a note.
dsinger: The note isn't even finished.
hober: Works to me, a table, which the 608 mapping document can
refer to.
silvia: It makes sense to put it into the spec itself is that
it is not 608 and 708 specific,
... as atai pointed out. Having foreground and background color
is something everyone wants.
... Then 608/708 can reference it.
dsinger: This is the only color set well defined in the
industry, true?
silvia: yes
<silvia> I meant: the 608/708 to vtt mapping spec
atai: As basic support that's what we need
hober: we have agreement on UAs that don't support CSS.
... Do we also require CSS supporting UAs to load the
stylesheet?
silvia: It should be available to all.
atai: I agree with silvia
dsinger: I thought so too until a few days ago and then I
thought there is an advantage
... in including the CSS styles of the colours you are using in
the document so it is self-complete.
... Maybe more important for the VTT file to work everywhere.
hober: Yes much more important.
dsinger: So all UAs behave as though those classes are
predefined.
silvia: So we'll put those colours plus mappings into an
appendix and say they are a base
<dsinger> a) put that style-sheet into an annex (b) all UAs
must behave as if that style-sheet were pre-loaded
silvia: set of classes that every UA supporting VTT needs to
support?
<hober> hober: not the whole stylesheet; just the bits defining
the colors
<dsinger> in section 3 of
[114]https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toV
TT/608toVTT.html
[114] https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html
<silvia>
[115]https://github.com/w3c/webvtt/pull/395#issuecomment-341857
127
[115] https://github.com/w3c/webvtt/pull/395#issuecomment-341857127
RESOLUTION: we include the class Lime with a note saying that
what 608 calls Green, we call Lime
<scribe> scribe: dsinger
These are formally the UA style sheet as defined by CSS
general discussion
[116]https://github.com/w3c/webvtt/issues?q=is%3Aopen+is%3Aissu
e+label%3AWR-open
[116] https://github.com/w3c/webvtt/issues?q=is:open+is:issue+label:WR-open
<silvia> [117]https://github.com/w3c/webvtt/issues/385
[117] https://github.com/w3c/webvtt/issues/385
<silvia> [118]https://www.w3.org/TR/webvtt1/
[118] https://www.w3.org/TR/webvtt1/
<silvia> wrong link: [119]https://w3c.github.io/webvtt/
[119] https://w3c.github.io/webvtt/
<silvia> [120]https://github.com/w3c/webvtt/issues/384
[120] https://github.com/w3c/webvtt/issues/384
notes that we have an authoring guide at
[121]https://www.w3.org/wiki/VTT_Concepts
[121] https://www.w3.org/wiki/VTT_Concepts
Silvia: this is fundamental discussion about the structure of
the spec and it seems rather late to change that
<Zakim> dsinger, you wanted to discuss the document retrieved
from web platform docs
<silvia> [122]https://github.com/w3c/webvtt/pull/398
[122] https://github.com/w3c/webvtt/pull/398
RESOLUTION: do not address the algorithmic nature of the VTT
spec at this time; but editors to improve 6.1 and its
readability as much as they can
... co-chair (ds) to edit the Wiki to warn it might not be up
to date, all to improve to make it up to date as they can
<silvia> [123]https://github.com/w3c/webvtt/issues/383
[123] https://github.com/w3c/webvtt/issues/383
<silvia> [124]https://github.com/w3c/webvtt/issues/381
[124] https://github.com/w3c/webvtt/issues/381
RESOLUTION: We insert a NOTE that in Cue text or Comment
blocks, you cannot have a blank line or -->, and that if they
are a possibility you will need to define an escape syntax
suitable to what you are embedding.
[125]https://github.com/w3c/webvtt/issues/378
[125] https://github.com/w3c/webvtt/issues/378
<silvia> [126]https://github.com/w3c/webvtt/issues/377
[126] https://github.com/w3c/webvtt/issues/377
[127]https://github.com/w3c/webvtt/issues/376
[127] https://github.com/w3c/webvtt/issues/376
[128]https://github.com/w3c/webvtt/issues/373
[128] https://github.com/w3c/webvtt/issues/373
Meeting wrap-up
<nigel> nigel: Thanks everyone for a really productive positive
two days of meetings.
<nigel> dsinger: Thank you Silvia for sacrificing your Saturday
morning!
<nigel> dsinger: Really positive
<nigel> nigel: We'll finalise details of the next TTWG F2F in
next week's call
<silvia> Thanks, I think we addressed the important open issues
on WebVTT!
<nigel> nigel: Meeting adjourned!
<nigel> atai: Thank you Nigel for scribing
<nigel> silvia: Thank you, we made really good progress
<silvia> bye!
<nigel> nigel: [meeting adjourned]
Summary of Action Items
Summary of Resolutions
1. [129]Approve IMSCvNext requirements pull request #10
2. [130]Add a note to say: Note: The application of
fillLineGap does not result in hiding any character glyphs
that would be visible without fillLineGap. Therefore after
application of fillLineGap all parts of all character
glyphs with a background colour behind them continue to
have that background colour applied.
3. [131]We do not need to refer to the Encoding spec and do
not need to make any change.
4. [132]Add "which is a" before "descendant".
5. [133]Mark rubyAlign="withBase" as at risk for CR
6. [134]Mark rubyAlign="withBase" as at risk for CR
7. [135]We do not need fontVariant for half vs full width or
superscript/subscript
8. [136]Adopt linePadding in TTML2, remove inlineAreaBreak,
keep padding on content
9. [137]Do not deprecate ebutts:multiRowAlign, prohibit inline
block, leave TTML2 as is.
10. [138]Remove ttp:mediaOffset as it stands and open a new
issue to explain how to resolve media time
11. [139]Remove ttp:mediaDuration
12. [140]Add ttm:alt attribute to TTML2 and permit it in IMSC
1.1 and deprecate ittm:altText in IMSC 1.1
13. [141]Keep itts:forcedDisplay in IMSC 1.1 and do not add
anything to TTML2
14. [142]Remove fillLineGap from TTML2 and retain
itts:fillLineGap in IMSC 1.1.
15. [143]Retain ittp:aspectRatio in IMSC 1.1 and add a note
explaining the equivalence to ttp:displayAspectRatio in
TTML2
16. [144]Remove linePadding from TTML2
17. [145]keep ittp:activeArea in IMSC 1.1, modify TTML2
ttp:activeArea to take position instead of origin,
informatively note value mapping from ittp:activeArea to
ttp:activeArea
18. [146]Deprecate smpte:backgroundImage in IMSC 1.1 in favour
of TTML2 image
19. [147]Deprecate ittp:progressivelyDecodable
20. [148]Reference details of deprecated
ittp:progressivelyDecodable from source in IMSC 1.0.1
21. [149]We plan to recharter from 1st April 2018.
22. [150]we include the class Lime with a note saying that what
608 calls Green, we call Lime
23. [151]do not address the algorithmic nature of the VTT spec
at this time; but editors to improve 6.1 and its
readability as much as they can
24. [152]We insert a NOTE that in Cue text or Comment blocks,
you cannot have a blank line or -->, and that if they are a
possibility you will need to define an escape syntax
suitable to what you are embedding.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [153]scribe.perl version
1.152 ([154]CVS log)
$Date: 2017/11/11 01:30:00 $
[153] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[154] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 20 November 2017 12:02:46 UTC