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