IRC log of tt on 2017-01-12

Timestamps are in UTC.

09:10:19 [RRSAgent]
RRSAgent has joined #tt
09:10:19 [RRSAgent]
logging to http://www.w3.org/2017/01/12-tt-irc
09:10:21 [trackbot]
RRSAgent, make logs public
09:10:21 [Zakim]
Zakim has joined #tt
09:10:23 [trackbot]
Zakim, this will be TTML
09:10:23 [Zakim]
ok, trackbot
09:10:24 [trackbot]
Meeting: Timed Text Working Group Teleconference
09:10:24 [trackbot]
Date: 12 January 2017
09:11:15 [nigel]
Present: Pierre, Andreas, Glenn, Thierry, Nigel, Dae
09:11:43 [nigel]
Regrets: Rohit
09:11:46 [nigel]
Chair: Nigel
09:11:48 [nigel]
scribe: nigel
09:11:56 [nigel]
Topic: Agenda
09:18:37 [glenn]
glenn has joined #tt
09:31:11 [nigel]
nigel: Welcome everyone, this is the first day of our F2F meeting in London.
09:32:57 [nigel]
nigel: Scans through agenda topics
09:37:04 [nigel]
nigel: We have approximately 12 hours, and a large number of issues on TTML1 and TTML2.
09:38:12 [nigel]
Pierre: The goal from a Movielabs perspective is to resolve all bugs, where resolve could mean deferring to TTML v>2.
09:43:30 [nigel]
nigel: We should use github milestones so we can clearly indicate which issues need to be resolved.
09:43:56 [nigel]
Andreas: For IRT the focus should be on TTML1 bugs and editorial issues and also IMSC1.
09:44:14 [nigel]
Thierry: We can move editorial issues to a later CR revision.
09:45:48 [nigel]
Glenn: When we go to CR we have to list Exit Criteria and any At Risk features. Since at risk
09:46:08 [nigel]
... features may be removed, we may make substantive changes after "WR" (working draft for wide review).
09:46:28 [nigel]
... Most TTML1 issues have equivalents in TTML2 also so we should be able to tackle them together.
09:50:47 [nigel]
nigel: Looking at time, we have many TTML issues and a more limited set of IMSC ones.
09:51:02 [nigel]
Pierre: I'm confident we can deal with all the IMSC topics in 4 hours.
09:51:09 [nigel]
nigel: Then let's cover those all this afternoon.
09:51:21 [nigel]
Dae: Let's cover TTML1 issues this morning then.
09:51:58 [nigel]
group: General agreement to do TTML1 on day 1 am, IMSC day 1 pm, TTML2 day 2.
09:52:38 [nigel]
Andreas: I prepared some slides about the relationship between TTML and XSL-FO, mainly to do with the line gap issue, and also to clarify it in general.
09:52:44 [nigel]
nigel: Is this for TTML1?
09:52:53 [nigel]
Andreas: Both TTML1 and TTML2.
09:53:14 [nigel]
nigel: Is there any other business to raise?
09:54:03 [nigel]
nigel: If there's time and interest I could give an update on the live TTML work that we're doing here.
09:58:19 [nigel]
Topic: TTML1 Issues
10:00:42 [nigel]
Andreas: I have a short presentation. [goes through slides]
10:00:51 [nigel]
.. TTML and XSL-FO
10:01:47 [nigel]
.. This is still a draft, so apologies if there are things not 100% correct.
10:02:01 [nigel]
.. TTML does not use XSL-FO and makes clear it is not needed for rendering.
10:02:13 [nigel]
.. TTML relies on XSL-FO as a conceptual model to define normative presentation semantics.
10:02:53 [nigel]
.. First step of rendering is TTML -> ISD -> XSL-FO Doc
10:03:03 [nigel]
.. according to the algorithm described in TTML1.
10:03:20 [nigel]
.. XSL-FO document is a "result tree".
10:03:34 [nigel]
Glenn: The first step is 1-> many, the next is 1->1.
10:03:40 [nigel]
Andreas: Yes.
10:03:59 [nigel]
.. Formatting is similar to HTML to DOM.
10:04:50 [nigel]
.. The result tree goes to the object tree; most of it looks the same, but for every character
10:05:04 [nigel]
.. you create a new object, an inline area. That may be important for some of what we are doing.
10:05:22 [nigel]
.. Phase 2: XSL-FO Doc -> Objectified FO-Tree -> Refined FO-Tree.
10:05:46 [nigel]
.. Refinement includes shorthand expansion, mapping of properties, computation of values, whitespace handling, inheritance.
10:06:09 [nigel]
.. Phase 3: Refined FO-Tree -> FO Area Tree -> Rendered Content.
10:06:19 [nigel]
Glenn: The FO Area Tree is similar to the CSS Box tree.
10:06:40 [nigel]
Andreas: Exactly, and XSL-FO relates its areas to CSS Boxes so you can see the correspondence.
10:06:59 [nigel]
.. The Area tree is an ordered tree, with geometric information for placement of every glyph, shape etc.
10:07:19 [nigel]
.. Each FO object could be mapped to an area, e.g. fo:block -> block areas + line areas.
10:07:29 [nigel]
.. fo:inline -> inline areas
10:07:37 [nigel]
.. fo:character -> glyph area
10:07:58 [nigel]
.. It could be that one object creates multiple areas, e.g. multiple inline areas.
10:09:03 [nigel]
.. XSL areas do not have "properties" but "traits" in the spec.
10:09:09 [nigel]
.. such as padding etc.
10:09:31 [nigel]
Glenn: The distinction between properties and traits: we have this distinction between
10:09:45 [nigel]
.. specified value, used value, computed value, actual value etc. and you can think of the
10:10:02 [nigel]
.. XSL object properties as being closer to specified or computed values, and the area traits
10:10:11 [nigel]
.. as being closer to used values or actual values.
10:10:19 [nigel]
.. In XSL you have attributes, properties and traits.
10:10:36 [nigel]
.. There are lots of labels applied to different concepts.
10:10:54 [nigel]
Andreas: Area Rectangles have a border rectangle, a padding rectangle and a content rectangle.
10:11:13 [nigel]
.. In TTML1 only the Region generates a separate padding rectangle. Others do in TTML2.
10:11:23 [nigel]
.. Also in TTML1 we have no border rectangle but we do have one for TTML2.
10:11:31 [nigel]
Glenn: In CSS there is also the margin rectangle.
10:11:48 [nigel]
Andreas: XSL-FO does not have margins but it has space before and space after, which correspond.
10:12:01 [nigel]
Nigel: Can they equally be negative, like CSS margins?
10:12:06 [nigel]
Glenn: I believe so.
10:13:21 [nigel]
Glenn: Every area is generated by exactly one object.
10:13:28 [nigel]
.. Some objects generate more than one area.
10:13:55 [nigel]
Andreas: Line Areas.
10:14:13 [nigel]
.. Some terms need clarifying, that are used in XSL-FO.
10:14:49 [nigel]
.. Nominal-requested-line-rectangle. before-edge and after-edge.
10:15:24 [nigel]
.. For example a block area with font-size 20px and line-height 25px, then the nominal
10:16:06 [nigel]
.. requested line rectangle is 20px and related to the dominant baseline.
10:16:27 [nigel]
Glenn: It's key to note that the nominal requested line rectangle is based on the parent element's font - it can only be one font.
10:16:47 [nigel]
Andreas: That's really important. The area tree has a nominal font, and you need to know
10:17:01 [nigel]
.. which font is used. Every glyph has an assigned nominal font. The font's font table
10:17:09 [nigel]
.. indicates the ascender and descender.
10:17:51 [nigel]
Glenn: For example the block level object like a p might have a font that is "Arial, xxx, yyy"
10:18:04 [nigel]
... and for the purpose of computing the requested line rectangle it will use one of those,
10:18:15 [nigel]
.. usually the first one, and it will use the font size that applies to the paragraph. Then when
10:18:30 [nigel]
.. you divide the content into spans or inline areas, then each of the characters may end up
10:18:44 [nigel]
.. being associated with a different actual font, and those fonts may have different
10:18:48 [nigel]
.. altitudes and depths.
10:20:05 [nigel]
Andreas: Back to the slides, the 20px is the difference between the before edge and the after edge, and is independent of the line height.
10:20:37 [nigel]
.. Then the expanded-nominal-requested-line-rectangle includes half-leading, being
10:20:53 [nigel]
.. half the difference between the computed value of the line-height property adn the computed value of the
10:21:01 [nigel]
.. sum of the ascender and descender.
10:21:24 [nigel]
.. Example image, showing expanded nominal requested line rectangle being 2.5px greater
10:21:49 [nigel]
.. than the inline one both above and below, so the inline area is 20px (font-size) and the expanded
10:21:58 [nigel]
.. area is 25px (line height).
10:22:04 [nigel]
Glenn: This is ยง4.5 of XSL-FO.
10:22:18 [nigel]
.. Some of these depend on the line stacking property.
10:22:23 [nigel]
Andreas: I will come back to that.
10:23:51 [nigel]
.. Then the Expanded-rectangle of an inline-area has a before-edge and after-edge which
10:24:10 [nigel]
.. outside the allocation rectangle by a distance equal to the half-leading, on condition that
10:24:21 [nigel]
.. the area's allocation rectangle is normal-allocation-rectangle.
10:25:25 [nigel]
Glenn: We need to add support for line-height on span in TTML2 for Ruby.
10:25:30 [nigel]
Nigel: we have an issue for that already.
10:25:33 [nigel]
Glenn: It's #131.
10:25:48 [nigel]
.. Also we now have padding and border on span in TTML2 so the large allocation rectangle
10:25:58 [nigel]
.. may have to take into account the padding and border on inline areas.
10:26:06 [nigel]
Andreas: Yes it gets more complicated in TTML2.
10:27:32 [nigel]
.. Expanded-rectangle: shows slide with an expanded rectangle for each character.
10:28:19 [nigel]
Glenn: For inline content, there's a major question how to define the bpd.
10:28:36 [nigel]
.. I'm not sure it is exactly ascender + descender; in CSS it is certainly not specified.
10:28:52 [nigel]
.. One way to expand the content rectangle to avoid gaps is to specify the content bpd.
10:29:03 [nigel]
.. Another way is some kind of automatic computation of padding and then use the expanded
10:29:15 [nigel]
.. rectangle, in other words "auto padding" but that would have to intersect with how we
10:29:20 [nigel]
.. use manual padding in TTML2.
10:29:36 [nigel]
Andreas: That's true. Coming back to the conceptual points...
10:29:47 [nigel]
.. Line areas and line-stacking-strategy.
10:29:59 [nigel]
.. Line stacking strategy has to be defined, and has different values. TTML explicitly
10:30:17 [nigel]
.. specifies "line-height" which means the allocation rectangle is the per-inline-height-rectangle.
10:30:38 [nigel]
.. We know what that is: its extent in the block progression dimension is the minimum required
10:30:56 [nigel]
.. to enclose the expanded-nominal-requested-line-rectangle and the expanded-rectangles
10:31:05 [nigel]
.. of all the inline-areas stacked within the line-area.
10:31:15 [nigel]
.. This may vary depending on the descendants of the line-area.
10:31:31 [nigel]
Glenn: That can mean that different lines with the same line height and font size can have
10:31:47 [nigel]
.. different bpd depending on the padding and border - that's not an issue in TTML1.
10:32:09 [nigel]
Andreas: This applies also to all descendants of the line area, not just the direct children.
10:33:19 [nigel]
.. Example with an inline area that has a bigger font size of the block area, which expands the
10:33:49 [nigel]
.. line's size in the block progression dimension, for the whole line.
10:34:02 [nigel]
Glenn: The baseline position within the whole line area may go up or down depending on
10:34:25 [nigel]
.. the font of the largest character area - it may have a different altitude:depth ratio than the
10:34:39 [nigel]
.. other character areas.
10:34:54 [nigel]
Pierre: So with this strategy you are not guaranteed to get the line-height that is requested.
10:35:29 [nigel]
Andreas: Correct, if a p has line-height 25px and one of its descendants has a line-height 40px
10:35:37 [nigel]
.. then the actual line-height would be 40px.
10:35:52 [nigel]
Glenn: If we used a different line stacking strategy then you could end up with glyphs on
10:36:01 [nigel]
.. one line overlapping glyphs on adjacent lines.
10:41:52 [nigel]
.. [shows examples]
10:43:28 [nigel]
.. First example shows how larger font size spans in a line can extend the line height.
10:43:55 [nigel]
.. Second example shows a nested span where the parent has (non-inheritable) background color of green,
10:44:13 [nigel]
.. and child has larger font size than the line height, and result is that the green is only painted
10:44:39 [nigel]
.. with the height of the parent p element's specified line-height but the glyph areas are larger.
10:46:06 [nigel]
Nigel: Does this provide guidance for how we solve the issue of gaps between background areas behind adjacent lines?
10:46:16 [nigel]
Andreas: It shows how complex this is!
10:46:36 [nigel]
Glenn: You can't simply increase the height, you also need to keep the baseline consistent.
10:47:45 [nigel]
Andreas: I will make these slides available, but may need to adjust them a little first.
10:48:28 [nigel]
Nigel: One key point from this is that the actual rendering depends on the font chosen at
10:48:38 [nigel]
.. rendering time, which is not necessarily known at authoring time.
10:49:55 [nigel]
Glenn: One thing that is useful is to use tools that can show the calculated areas, which many browsers do in developer mode.
10:50:12 [nigel]
Andreas: In FOP you can export the area tree, which is useful.
10:50:32 [nigel]
Glenn: TTPE generates an area tree and hands it off to a renderer.
10:51:43 [nigel]
Nigel: Let's move to the TTML1 issues labelled "bug":
10:51:52 [nigel]
-> https://github.com/w3c/ttml1/issues/221
10:52:54 [nigel]
Glenn: Basically the question is whether padding is inside or outside the extent of the region.
10:53:09 [nigel]
.. I have no doubt that the intention in TTML1 was that it would be inside not outside.
10:53:27 [nigel]
.. So it would make no sense to define padding or border otherwise. What we may not have
10:53:47 [nigel]
.. done very well is how we specified the mapping to XSL-FO. If we had specified it as mapping
10:54:02 [nigel]
.. to a pair of outer and inner block container, with the inner one having the padding or border
10:54:11 [nigel]
.. on it then there would have been no problem here.
10:55:12 [nigel]
nigel: So we are all agreed there is a problem with the spec, and the resolution is a change
10:55:17 [nigel]
.. to the mapping to XSL-FO?
10:55:33 [nigel]
Glenn: The mapping to XSL-FO tries to be normative so this is substantive.
10:55:50 [nigel]
Pierre: The text is clear in TTML that it says it is inset, but the confusion is caused by the
10:56:05 [nigel]
.. reference to terms used also in XSL-FO such as padding and border, where there is not
10:56:10 [nigel]
.. a 1:1 correspondence in fact.
10:56:18 [nigel]
Andreas: We should try to keep the correspondence if possible.
10:57:18 [nigel]
Pierre: Does anybody disagree with the interpretation is that padding does not extend the
10:57:23 [nigel]
.. extent of the region?
10:57:37 [nigel]
Andreas: The problem is if I had to decide right now I would make it the same as XSL-FO.
10:57:52 [nigel]
.. This is likely different from the intent of the spec though.
11:02:05 [nigel]
Glenn: [Describes proposal with an inner and outer block, using whiteboard]
11:02:21 [nigel]
Pierre: Mapping to HTML and CSS you would not have two divs though.
11:03:15 [nigel]
Glenn: Yes that's what you would do, set padding on the inner div, and set the extent of the outer div from the region.
11:04:09 [nigel]
Pierre: So you use the layout engine to avoid calculating the adjusted extent having subtracted padding?
11:04:11 [nigel]
Glenn: Yes.
11:05:00 [nigel]
Andreas: But the height of the inner block would not be specified, so it would not extend to the full height of the outer block.
11:05:31 [nigel]
Pierre: We all seem to be agreed on the desired outcome, so someone can take the task to
11:05:35 [nigel]
.. find a solution that works.
11:05:43 [nigel]
Nigel: With a fiddle or a codepen etc...
11:05:46 [nigel]
Pierre: Exactly.
11:07:21 [nigel]
Glenn: I think we have agreement on the intended results, so it's for me to find a solution unless someone wants to volunteer?
11:07:24 [nigel]
Andreas: I can do that.
11:07:37 [nigel]
Glenn: I don't want to change it so it maps the outer region to a content rectangle.
11:09:14 [nigel]
Andreas: I will aim to do this by beginning of Feb.
11:11:41 [nigel]
nigel: I've added a note to the issue.
11:11:53 [nigel]
-> https://github.com/w3c/ttml1/issues/216
11:12:08 [nigel]
nigel: Process [construct intermediate document] prunes "set" elements. #216
11:12:23 [nigel]
Glenn: That's clear, assign it to me and give it a 3rd edition milestone.
11:14:02 [nigel]
nigel: I've added a note and a milestone to the issue.
11:14:23 [nigel]
-> https://github.com/w3c/ttml1/issues/206 Use of 'em' units in tts:fontSize on region element is not well defined. #206
11:19:58 [nigel]
group: Discusses and agrees proposal to make 1em be the same as 1c which is the same as 100%.
11:25:25 [nigel]
-> https://github.com/w3c/ttml1/issues/227 Should tts:direction apply only to <span>? #227
11:25:33 [nigel]
Pierre: I want to decide if this is a bug.
11:25:53 [nigel]
.. I discovered that in XSL tts:direction only applies to inline areas and that writing mode sets
11:26:12 [nigel]
.. the block level element direction, and this seems to be different to how CSS behaves.
11:26:28 [nigel]
nigel: Do we think it's a bug?
11:26:50 [nigel]
Pierre: I think it's a bug because it will lead to unexpected behaviour in implementations as it is.
11:27:07 [nigel]
Andreas: It is really hard to see the dependencies between direction and writingMode. There's not much text in it.
11:27:14 [nigel]
Glenn: It relies on the semantics in XSL.
11:27:31 [nigel]
Pierre: That's fine, and in XSL it states that direction does not apply to block level elements
11:27:58 [nigel]
.. so it should not apply to p in TTML, and if we make that change then it fixes it in HTML too.
11:28:16 [nigel]
Dae: Or you could make tts:direction on a p really change XSL writing-mode?
11:28:52 [nigel]
Glenn: No, only region should have writing-mode. Direction only applies to inline bidi functionality.
11:28:58 [nigel]
Pierre: That was my conclusion too.
11:29:56 [nigel]
Glenn: In the special case of p direction specifies the default writing mode, which is in XSL but it's
11:30:03 [nigel]
.. in a different place where the bidi algorithm is covered.
11:32:22 [Zakim]
Zakim has left #tt
11:33:41 [Zakim]
Zakim has joined #tt
11:35:04 [nigel]
Glenn: Notes that there is already a resolution to this in TTML2 for https://github.com/w3c/ttml2/issues/142
11:35:43 [nigel]
Pierre: [tries that solution out using an IRT test vector]
11:35:51 [nigel]
Andreas: Maybe we need to come back to this later.
11:36:38 [nigel]
.. I'm not clear why writing mode is inheritable in XSL but not in TTML.
11:36:55 [nigel]
Glenn: In fact in implementations its effect is inherited because in every implementation you
11:37:08 [nigel]
.. need to be able to say for any given area what its writing mode is, and that is answered by
11:37:15 [nigel]
.. looking at the writing mode.
11:42:09 [nigel]
Pierre: References XSL that maps writing mode to direction, but the relationship of this to TTML interpretation of direction is unclear.
11:42:26 [nigel]
Glenn: I'm glad that you've raised the other issue, what to rl and lr mean in a vertical writing mode?
11:44:06 [nigel]
-> https://www.w3.org/TR/2006/REC-xsl11-20061205/#direction 2nd bullet in XSL modifications to the CSS definition
11:44:27 [nigel]
-> https://www.w3.org/TR/2006/REC-xsl11-20061205/#compcorr
11:44:44 [nigel]
Andreas: the above maps the start and end values.
11:44:48 [nigel]
Pierre: okay that should work.
11:45:12 [nigel]
Nigel: So is there anything left to do on the issue?
11:49:05 [nigel]
Glenn: I don't think there's a bug here but some clarification notes could be valuable.
11:50:50 [nigel]
Andreas: I think it's really hard for implementers right now to understand the interaction between
11:50:56 [nigel]
.. direction and writingMode.
12:02:02 [nigel]
rrsagent, make minutes
12:02:02 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/01/12-tt-minutes.html nigel
12:06:19 [nigel]
-> https://github.com/w3c/ttml1/issues/219 Step 10.4.4.2(6)(a) does not apply to textDecoration. #219
12:07:42 [nigel]
-> https://github.com/w3c/ttml2/issues/219 (same issue in TTML2)
12:08:24 [nigel]
Pierre: I think the intent is that each component should be inherited separately.
12:08:38 [nigel]
Glenn: In CSS there are shorthand and longhand properties; we don't have that.
12:08:56 [nigel]
.. In CSS the shorthands map to longhands and the inheritance applies at the longhand level.
12:09:12 [nigel]
Nigel: Where longhand is each property separately specified?
12:09:14 [nigel]
Glenn: That's right.
12:09:38 [nigel]
.. So we need to note that inheritance is intended to occur in the same fashion here,
12:09:46 [nigel]
.. without introducing the longhand properties.
12:13:37 [nigel]
group: Agreed action to be taken, added note to issue.
12:13:59 [nigel]
-> https://github.com/w3c/ttml1/issues/218 Use of cell metric in tts:textOutline. #218
12:14:13 [nigel]
-> https://github.com/w3c/ttml2/issues/217 (equivalent in TTML2)
12:14:55 [nigel]
Nigel: We've discussed and agreed this for TTML2 so just need to note that on the TTML1 issue.
12:17:49 [nigel]
.. Same for TTML1 #215 -> TTML2 #200.
12:18:37 [nigel]
-> https://github.com/w3c/ttml1/issues/214 Clarify the semantics of tts:fontSize="2em". #214
12:18:49 [nigel]
nigel: This is related to #206 that we discussed and agreed earlier.
12:22:11 [nigel]
Pierre: It is not clear that em units on font size are relative to the parent element's font size.
12:22:28 [nigel]
Glenn: I think it does say this by reference to XSL-FO which in turn references CSS.
12:26:12 [nigel]
Nigel: I've added a note to the issue and also to https://github.com/w3c/ttml2/issues/216
12:27:24 [nigel]
-> https://github.com/w3c/ttml1/issues/205 Clarify meaning of percentage with writing mode relative edge terms in tts:padding. #205
12:28:03 [nigel]
Nigel: This is a sparse issue report!
12:28:19 [nigel]
Glenn: It's also logged in TTML2 as https://github.com/w3c/ttml2/issues/144
12:31:37 [nigel]
group: decides this issue is: The question here is, for tts:padding="1% 2% 3% 4%" are the values related to absolute height and width or writing mode relative dimensions?
12:32:17 [nigel]
Pierre: The current text may be surprising but it is not ambiguous. I would not change anything.
12:32:30 [nigel]
Glenn: I agree there's no technical change needed just a note to clarify.
12:32:56 [nigel]
Pierre: Here the width and height of the region are independent of the writing mode.
12:33:12 [nigel]
Nigel: So they are just the first and second component of the tts:extent of the region.
12:39:28 [nigel]
nigel: Let's break for lunch - I think we have a few more TTML1 issues to run through.
12:39:31 [nigel]
rrsagent, make minutes
12:39:31 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/01/12-tt-minutes.html nigel
13:39:38 [Zakim]
Zakim has left #tt
13:48:55 [nigel]
nigel: Going through remaining issues.
13:51:30 [nigel]
-> https://github.com/w3c/ttml1/issues/197 The [Construct Intermediate Document] process erroneously prunes empty <br> elements. #197
13:53:43 [nigel]
nigel: Added notes to the issue
13:53:52 [nigel]
-> https://github.com/w3c/ttml1/issues/194 Ambiguous definition for determination of descendant region identifier. #194
13:53:59 [nigel]
glenn: Can we come back to this in the morning?
13:54:07 [nigel]
Nigel: Yes, marking as a bug for now.
14:01:11 [nigel]
-> https://github.com/w3c/ttml1/issues/193 Inconsistent implicit duration of singleton span in sequential container. #193
14:01:28 [nigel]
Glenn: I want to mark this as a bug until I prove it isn't one.
14:02:56 [nigel]
.. But I need time to review it. I have already done this in TTML2.
14:05:42 [nigel]
Pierre: I implemented this in imscjs as all anonymous spans that are children of seq timeContainers have implicit duration of zero.
14:06:58 [nigel]
Nigel: I've marked it as a bug and added a note that we need to come back to it.
14:07:14 [nigel]
-> https://github.com/w3c/ttml1/issues/196 Handling forward interoperability of attribute extensions in TT namespaces. #196
14:11:32 [nigel]
Nigel: I think this has a potentially big impact since we want to be able to add attributes in
14:11:44 [nigel]
... existing namespaces and have TTML1 processors that do not understand those attributes
14:11:47 [nigel]
... prune them out.
14:14:55 [nigel]
Nigel: Okay, I've updated the issue.
14:23:01 [nigel]
-> https://github.com/w3c/ttml1/issues/220 Computed value of lineHeight and inheritance. #220
14:23:07 [nigel]
Pierre: This needs to be fixed.
14:24:59 [nigel]
.. I think we have agreed that the "normal" value should be inherited before calculating the computed value.
14:25:01 [nigel]
Nigel: Agreed.
14:29:25 [nigel]
.. I've updated the issue.
14:29:53 [mike]
mike has joined #tt
14:30:13 [mike]
good mornong/afternoon
14:32:05 [mike]
ok, thanks
14:35:33 [mike]
the standing Thursday webex?
14:37:10 [mike]
I ask since I get: "Time remaining until you can join: 19:46"
14:38:01 [nigel]
Topic: IMSC
14:38:10 [nigel]
Present+ Mike
14:38:29 [nigel]
s/ok, thanks//
14:38:35 [nigel]
s/the standing Thursday webex?//
14:38:45 [nigel]
s/I ask since I get: "Time remaining until you can join: 19:46"//
14:38:51 [nigel]
rrsagent, make minutes
14:38:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/01/12-tt-minutes.html nigel
14:39:41 [nigel]
-> https://www.w3.org/wiki/TimedText/F2F-jan-2017#Specification_Topics
14:40:44 [nigel]
Pierre: The scope: IMSC v.next is urgent modifications to IMSC1 that do not result in existing IMSC1 implementations to be non-conformant.
14:40:54 [nigel]
.. We got a number of responses by liaison.
14:41:03 [nigel]
.. Start with ATSC - they said they have nothing to add.
14:41:20 [nigel]
.. ARIB said something similar, and said they are interested in TTML2.
14:51:32 [nigel]
Nigel: I just want to come back to the scope description. I think it's ambiguous what the
14:51:50 [nigel]
.. existing IMSC1 implementations shall remain conformant to: I would say that they shall
14:52:01 [nigel]
.. remain conformant to IMSC1, but not necessarily IMSC 1.1
14:52:24 [nigel]
Pierre: That's not what I understood and not what I could accept - IMSC 1 processors have
14:52:38 [nigel]
.. to remain conformant against any short term update IMSC 1 specification. That means
14:52:52 [nigel]
.. that any new features have to be defined with SHOULDs rather than SHALLs.
14:53:18 [nigel]
Nigel: Okay in that case we cannot get consensus on any features with SHALL requirements
14:53:36 [nigel]
.. even for IMSC 1.1 processors, and even though IMSC 1 processors would ignore the newly
14:53:40 [nigel]
.. introduced syntax.
14:53:49 [atai]
atai has joined #tt
14:54:08 [nigel]
Mike: Ideally for me we would not introduce any new features at all, but if we recognise that
14:54:21 [nigel]
.. some features will be done anyway then it's better to have them all specified in the same
14:54:35 [nigel]
.. way rather than multiple syntaxes for the same semantic.
14:55:15 [glenn]
glenn has joined #tt
14:56:39 [nigel]
Andreas: I would second Pierre's and Mike's view that we should not introduce new normative
14:57:01 [nigel]
.. SHALL requirements that would cause IMSC 1 processors non-conformant to IMSC 1.next.
14:57:13 [nigel]
Dae: I think that makes sense.
14:57:24 [nigel]
Pierre: I would move all normative requirements to IMSC 2.
14:58:01 [nigel]
Glenn: Are we aiming for a second edition or a 1.1?
14:58:48 [nigel]
Pierre: I think that would depend on what changes need to be made.
14:59:02 [nigel]
Thierry: The process is the same, if you bring new features you have to go through CR.
14:59:23 [nigel]
Pierre: The class of changes here would not affect conformance.
14:59:37 [nigel]
Thierry: It says "substantial" changes so we need to look at that in more detail.
15:00:08 [nigel]
Mike: A third possible course, so we think about it, would be to collect these things in a separate namespace and publish them as a Note.
15:00:55 [nigel]
Pierre: I think adding an extra document makes it harder for people to find the specification.
15:01:12 [nigel]
Nigel: I thought about that too and also would prefer a single complete IMSC 1.next document
15:01:19 [nigel]
.. whether it is a 1.1 or a second edition.
15:01:48 [nigel]
Glenn: There is always the option of a limited scope additional document as a stop-gap, which
15:01:57 [nigel]
.. could only be a few pages long and would be easier to get through the process.
15:02:10 [nigel]
Thierry: I would propose to go for a Proposed Edited Recommendation or something like that,
15:02:21 [nigel]
.. with a backup to create a new WG Note or something like that.
15:03:01 [nigel]
Nigel: I think if we introduce a new style attribute even if it's only got SHOULDs associated with it then it would still be considered a new feature.
15:03:05 [nigel]
Glenn: Yes it would.
15:03:10 [nigel]
Pierre: How could that be?
15:03:53 [nigel]
Nigel: Even if it's only a SHOULD then there's a thing with a defined behaviour that is a feature.
15:11:23 [nigel]
Nigel: Just to clarify, are you also saying that there would not be a new short code for an IMSC 1.next profile, so that
15:11:39 [nigel]
.. processors cannot be distinguished based on support for any newly introduced features?
15:11:47 [nigel]
Pierre: Yes.
15:13:55 [nigel]
Nigel: Okay I think the positions are clear enough now and we know where we stand enough to proceed. I'm not going to make it a showstopper that we shouldn't go ahead unless we plan to introduce normative requirements.
15:14:02 [nigel]
Pierre: Let's look at the DVB one then.
15:16:33 [nigel]
Pierre: there are issues already raised for that.
15:16:54 [nigel]
.. HbbTV next.
15:19:03 [nigel]
Mike: From a private conversation I understand that the HbbTV expectation was not that we would reproduce their existing processor requirement.
15:19:13 [nigel]
Nigel: Yes, that's my understanding too.
15:21:55 [nigel]
Pierre: SMPTE next.
15:35:19 [nigel]
Nigel: Ok that's all the liaisons, to summarise, we have requests for two features, which
15:35:29 [nigel]
.. Pierre has already created issues for. Let's look at them in turn:
15:36:31 [nigel]
Pierre: Actually there are a number of issues we can quickly close including those.
15:36:52 [nigel]
-> https://github.com/w3c/imsc/pull/192 addresses four issues:
15:37:11 [nigel]
-> https://github.com/w3c/imsc/issues/178 Highlight semantics of smpte:backgroundImage #178
15:37:31 [nigel]
-> https://github.com/w3c/imsc/issues/188 Example 4 typo - extent height #188
15:37:52 [nigel]
-> https://github.com/w3c/imsc/issues/189 Example 10 - fontHeight problem #189
15:38:09 [nigel]
-> https://github.com/w3c/imsc/issues/190 "green" is not quite green #190
15:41:12 [glenn]
https://www.w3.org/2013/09/ttml1-changes.html
15:46:52 [nigel]
group: [reviews PR] Nigel approves and merges.
15:47:06 [nigel]
-> https://github.com/w3c/imsc/issues/194 #zIndex feature is permitted but not used #194
15:47:27 [nigel]
-> https://github.com/w3c/imsc/pull/197
16:02:22 [nigel]
nigel: I made a request for a change.
16:02:33 [nigel]
-> https://github.com/w3c/imsc/issues/184 Potential conflict with respect to pixel aspect ratio. #184
16:04:48 [nigel]
Pierre: there's a pull request for this at https://github.com/w3c/imsc/issues/193
16:09:10 [atai_]
atai_ has joined #tt
16:11:09 [nigel]
Nigel: Okay, we reviewed that and approved and merged.
16:14:11 [nigel]
-> https://github.com/w3c/imsc/issues/195 Control background between adjacent lines #195
16:17:10 [nigel]
Mike: Is it computationally possible to derive the padding needed to make sure background areas don't have gaps?
16:17:27 [nigel]
Nigel: We reviewed this partially this morning with Andreas's presentation. Our conclusion is
16:17:47 [nigel]
.. that at authoring time it is not possible in general to compute the required padding values,
16:18:09 [nigel]
.. even if we had a mechanism in TTML1 to specify those padding values.
16:18:32 [nigel]
Andreas: In limited circumstances with XSL-FO conformant implementation and accurate
16:18:41 [nigel]
.. knowledge of the font used then it may be possible.
16:18:59 [nigel]
Glenn: I'm not convinced about that and certainly CSS implementations are not consistent.
16:19:24 [nigel]
Andreas: Going back to what kind of information is needed, you need the ascender and
16:19:40 [nigel]
.. descender of the font to get the content rectangle height.
16:19:52 [nigel]
Glenn: In the implementation area this is a problem because this could be on a per glyph
16:20:03 [nigel]
.. basis or a per glyph run basis, and what if there are multiple fonts on that run.
16:20:24 [nigel]
Andreas: The background is not inherited, and always applies to a span.
16:20:38 [nigel]
Glenn: The algorithm for determining the height of the span does take into account the
16:20:53 [nigel]
.. question of ascender and descender of both the paragraph's font and the font of each
16:21:03 [nigel]
.. individual glyph area for the inline area in question.
16:21:50 [nigel]
Nigel: We cannot add padding to span in TTML1 anyway.
16:21:55 [nigel]
Pierre: That could be one possible solution.
16:22:05 [nigel]
Glenn: It would not be adequate or reliable enough to achieve the desired results.
16:22:36 [nigel]
Mike: Thanks for that. I just wanted to make sure we weren't doing something in a way that could be done already a different way.
16:22:53 [nigel]
Andreas: I do not think we can use any TTML syntax to close the line gaps. The author has
16:23:05 [nigel]
.. no tool that they can use, but we can use concepts that already exist, and base new
16:23:27 [nigel]
.. syntax on existing tools like padding at rendering time, with a defined mapping to a conceptual model.
16:23:43 [nigel]
Glenn: That raises the other issue - even if we were to define a new style property that allows
16:23:59 [nigel]
.. us to define the area, it would leave us with the open problem of mapping to other
16:24:09 [nigel]
.. formatting systems where there is no support for this function, like CSS>
16:24:15 [nigel]
s/>/.
16:25:38 [nigel]
Nigel: It depends how complex a mapping we are willing to accept. I believe we could
16:25:52 [nigel]
.. do this by using a combination of HTML, CSS and JS to query the content rectangle at
16:25:58 [nigel]
.. presentation time and add padding to it.
16:31:37 [nigel]
Andreas: [shares presentation] There is no way to specify a background colour for a line
16:32:33 [nigel]
.. area in XSL-FO. There is no trait for it. So what you want to do is have the background
16:32:49 [nigel]
.. of each glyph area to the line height.
16:38:28 [nigel]
Glenn: It's easy enough to define a style attribute on the p element that affects the background
16:39:49 [nigel]
.. height of the inline areas generated from the descendant spans.
16:39:55 [nigel]
Nigel: I was heading in that direction too.
16:40:16 [nigel]
Glenn: But from this CSS rendering view it might be difficult to implement. I take your point you could do it with JS.
16:40:34 [nigel]
Andreas: There may be a difference between XSL-FO and CSS. It's not really the normative
16:40:42 [nigel]
.. reference but it helps to explain how this may work in CSS.
16:43:02 [nigel]
Andreas: If you know the content area then you can add padding to before and after edges to achieve the desired outcome.
16:43:25 [nigel]
Pierre: Yes, to implement this you would have to create many different spans and check the
16:43:46 [nigel]
.. padding to apply to them each individually. For example you could create a span per character.
16:46:16 [nigel]
Nigel: I think we need to be clear what the requirement is here. I think the simplest thing
16:46:36 [nigel]
.. would be a boolean flag that says "do it as now" or "extend in the block progression direction
16:46:59 [nigel]
.. the background so that the before edge of each glyph's background coincides with the line area's before edge
16:47:13 [nigel]
.. and the after edge coincides with the line area's after edge".
16:49:29 [glenn]
https://github.com/w3c/ttml2/issues/150#issuecomment-192490492
16:50:32 [nigel]
Mike: Perhaps a brute force way would be to use regions, but I understand that would have
16:50:36 [nigel]
.. a different effect.
16:50:52 [nigel]
.. Another is if we need to worry about images too. If the PNGs are all the same height or
16:51:14 [nigel]
.. width it all works out, but if they're not, say because the font size changes midline, then
16:51:18 [nigel]
.. what do you want it to look like.
16:51:42 [nigel]
Dae: The background colour on a region won't work because the positioning wouldn't work.
16:53:09 [nigel]
.. The gap between regions can not be guaranteed.
16:56:30 [nigel]
Glenn: I proposed a bpdContent attribute for inline elements with values like bpdLine.
16:56:46 [nigel]
.. There is a slight problem with making bpd on span make it an inline block, but I've been
16:56:58 [nigel]
.. considering separating that and specifying display separately anyway.
16:57:11 [nigel]
Nigel: That would solve an issue I opened too, I think it's a good idea.
16:59:06 [nigel]
Andreas: Changing the content rectangle size might have other effects on line stacking etc.
16:59:30 [nigel]
.. The question for me is if we can stick to something similar to what Nigel wrote, saying
16:59:45 [nigel]
.. "this is what we expect, good luck" or is we need to go deeper and explain more about how
16:59:56 [nigel]
.. to implement it. I'm not sure if we can do the second one.
17:00:02 [nigel]
Nigel: I'm not sure if we need to do the second one.
17:00:16 [nigel]
Glenn: One benefit of my approach is that we could propose it as a solution to the CSSWG.
17:02:30 [nigel]
nigel has joined #tt
17:04:01 [nigel_]
nigel_ has joined #tt
17:07:58 [nigel]
rrsagent, make minutes
17:07:58 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/01/12-tt-minutes.html nigel
17:09:40 [nigel]
Pierre: Based on what I've heard the simplest thing is a boolean style attribute that signals
17:09:55 [nigel]
.. the authorial intent, which we can add to IMSC1, then hopefully in the scope of IMSC2
17:10:05 [nigel]
.. and TTML2 then we can interface with the CSS folks and come up with something better.
17:12:15 [nigel]
Glenn: Can we make it a boolean switch on the root element?
17:12:34 [nigel]
Nigel: I don't understand why you'd make a style-affecting semantic have syntax in the parameter namespace.
17:12:54 [nigel]
Glenn: It's a lot easier to add new parameter attributes to my implementation than a new style attribute.
17:14:44 [nigel]
Nigel: Even the HbbTV heuristic allows for different presentations for different content in the same ISD, since it is based on the specified lineHeight
17:15:21 [nigel]
Andreas: To make it applicable document wide you could use the styling namespace and make
17:15:33 [nigel]
.. it like tts:extent and say it applies to p but only is significant on the tt element.
17:16:11 [nigel]
Nigel: It seems like we are converging on this boolean approach.
17:16:28 [nigel]
Pierre: I think we just need to pick one.
17:16:44 [nigel]
Nigel: I would pick a style attribute that is inheritable and applies to p.
17:18:01 [nigel]
Nigel: I think the namespace has to be itts.
17:18:15 [nigel]
Pierre: This can vary on different p elements.
17:18:24 [nigel]
Andreas: +1.
17:18:36 [nigel]
Pierre: Yes.
17:19:03 [nigel]
Nigel: I suggested a name "padToLine"
17:19:07 [nigel]
Glenn: I hate "pad"
17:20:46 [nigel]
Andreas: Something like "extendBackgroundToLine" works okay because it just talks about the background.
17:21:20 [nigel]
Nigel: "fillLineGap"?
17:21:29 [nigel]
Pierre: okay let's do that.
17:21:40 [nigel]
Glenn: Values are true or false?
17:21:42 [nigel]
Pierre: Yes
17:27:58 [nigel]
Pierre: Can we make it clear this is a SHOULD?
17:28:23 [nigel]
Nigel: We can make support for the feature optional but say that processors that do support it shall do it in a specified way.
17:28:39 [nigel]
Glenn: I suggest strongly that this is defined in a separate Note.
17:29:20 [nigel]
Nigel: While we consider this I have added a note to the issue.
17:30:15 [nigel]
Pierre: Thierry, can a Second Edition introduce new functionality, in your experience?
17:30:27 [nigel]
Thierry: If you ask anyone they will say its a case by case discussion with the Director.
17:31:06 [nigel]
.. A few years ago I would say no chance, but nowadays I'm not sure.
17:31:59 [nigel]
Nigel: Why don't I take an action to ask Wendy?
17:32:08 [nigel]
group: [discussion continues]
17:37:05 [nigel]
s/ask/chat to
17:39:11 [nigel]
Topic: TTML Profiles document
17:39:27 [nigel]
Mike: I resolved all the issues, created a pull, merged it, and walked you through it. So
17:39:40 [nigel]
.. folks were given until today to comment on it before we publish it. Does anyone have
17:39:49 [nigel]
.. any comments or concerns over the current document in github?
17:40:35 [nigel]
-> https://w3c.github.io/tt-profile-registry/
17:41:50 [nigel]
PROPOSAL: Publish the TTML Media Type Definition and Profile Registry as updated at https://w3c.github.io/tt-profile-registry/
17:42:07 [nigel]
RESOLUTION: We will publish the TTML Media Type Definition and Profile Registry as updated at https://w3c.github.io/tt-profile-registry/
17:42:45 [nigel]
Action: tmichel Publish the updated TTML profile registry at https://w3c.github.io/tt-profile-registry/ by 2017-01-19
17:42:46 [trackbot]
Created ACTION-492 - Publish the updated ttml profile registry at https://w3c.github.io/tt-profile-registry/ by 2017-01-19 [on Thierry Michel - due 2017-01-19].
17:44:42 [nigel]
Topic: IMSC
17:48:00 [nigel]
Pierre: I want to go back to the idea of specifying an optional feature support.
17:48:17 [nigel]
.. You would add a new category to prohibited and permitted that would be, say, optional.
17:48:21 [nigel]
.. That's your proposal Nigel?
17:48:38 [nigel]
Nigel: Yes. The difference between that and a should in a semantic specification is that if
17:49:01 [nigel]
.. supported it is clear what is mandated, but support is optional, as opposed to both
17:49:09 [nigel]
.. support being optional and the semantic being optional if supported.
17:49:29 [nigel]
.. This would add a new category to section 4.
17:49:40 [nigel]
Pierre: Okay I'll recast the pull request in that way and see what it looks like.
17:51:14 [nigel]
-> https://github.com/w3c/imsc/issues/198 recommendation for "end" but not "dur" #198
17:51:34 [nigel]
Pierre: IMSC 1 tries to help the author by recommending that begin and end attributes should always be specified for timing.
17:51:50 [nigel]
.. Mike you pointed out that begin and dur is not recommended even though it is also unambiguous.
17:52:07 [nigel]
.. The question is should the recommendation be removed or changed to permit begin and dur?
17:52:21 [nigel]
Mike: Yes, also it wasn't clear what this recommendation is for. I took it initially to mean you
17:52:35 [nigel]
.. shouldn't have indeterminate begin or end times. If there's another purpose it should be noted.
17:56:51 [nigel]
issue-382?
17:56:51 [trackbot]
issue-382 -- Require a computed non-indefinite begin time -- closed
17:56:51 [trackbot]
http://www.w3.org/AudioVideo/TT/tracker/issues/382
18:00:21 [nigel]
Mike: This causes a problem because validators issue warnings when dur is used instead of end even though it's actually fine.
18:00:59 [nigel]
Glenn: The recommendation is a reasonable constraint if you are also trying to create a conformant EBU-TT-D document.
18:01:30 [nigel]
Dae: We should just add the possibility of a dur attribute as an alternative to end.
18:02:09 [nigel]
Pierre: What's your thought on that proposal?
18:02:25 [nigel]
Mike: Can you have both end and dur?
18:02:32 [nigel]
Nigel: Yes but I think that's worth issuing a warning for!
18:04:28 [nigel]
-> https://github.com/w3c/imsc/issues/191 Add parameter signaling the editorial area of a document instance #191
18:07:48 [nigel]
Pierre: IMF has activeAreaRectangle which is named like that to be symmetric with other MXF terms.
18:08:33 [nigel]
.. "... shall be the rectangular region which is intended to be visible to the viewer at the sole discretion of the author. As such the active area rectangle may contain letterboxing or sign mattes."
18:08:46 [nigel]
s/.../activeAreaRectangle/
18:09:04 [nigel]
Glenn: I'm fine with activeArea and maybe informatively reference IMF for derivation purposes.
18:09:26 [nigel]
Pierre: The spec is SMPTE 2067-2:2016 Annex H.
18:10:26 [nigel]
Nigel: We need to clarify that normally the whole root container region is shown and only
18:10:57 [nigel]
.. in exceptional circumstances might that be cropped, but in that case the activeArea should
18:11:06 [nigel]
.. be shown in its entirety.
18:13:28 [nigel]
Pierre: We should definitely clarify that.
18:13:47 [nigel]
Mike: Why do we need to tell anyone that they have to display the captions that are there?
18:13:58 [nigel]
.. I think the bounding rectangle is a really good idea. My problem is with directing or
18:14:07 [nigel]
.. forbidding certain rendering behaviour. I just don't get it.
18:14:19 [nigel]
Andreas: So you would not recommend any presentation processor behaviour.
18:14:25 [nigel]
s/./?
18:14:28 [nigel]
Mike: That's correct.
18:14:37 [nigel]
Andreas: That leaves it up to others to define it.
18:14:47 [nigel]
Glenn: It would be a no-op if we did not define the purpose of it.
18:17:22 [nigel]
-> https://github.com/w3c/imsc/pull/196
18:21:55 [nigel]
Pierre: Can you propose an edit to take into account your review comment Nigel?
18:22:14 [nigel]
Nigel: OK I can't think enough to do it now though. I also think the note at the bottom needs to be moved closer.
18:22:50 [nigel]
Mike: As it stands this looks okay from a normative perspective - I cannot see any shoulds, shalls or mays.
18:23:06 [nigel]
Topic: Day 1 close
18:23:23 [nigel]
nigel: Thanks everyone, we've had a really full day and tackled a lot of issues! [adjourns meeting day 1]
18:23:27 [nigel]
rrsagent, make minutes
18:23:27 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/01/12-tt-minutes.html nigel
18:26:13 [nigel]
ScribeOptions: -final -noEmbedDiagnostics
18:26:17 [nigel]
rrsagent, make minutes
18:26:17 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/01/12-tt-minutes.html nigel