Timed Text Working Group Teleconference

12 Jan 2017

See also: IRC log


Pierre, Andreas, Glenn, Thierry, Nigel, Dae, Mike


<scribe> scribe: nigel


nigel: Welcome everyone, this is the first day of our F2F meeting in London.
... Scans through agenda topics
... We have approximately 12 hours, and a large number of issues on TTML1 and TTML2.

Pierre: The goal from a Movielabs perspective is to resolve all bugs, where resolve could mean deferring to TTML v>2.

nigel: We should use github milestones so we can clearly indicate which issues need to be resolved.

Andreas: For IRT the focus should be on TTML1 bugs and editorial issues and also IMSC1.

Thierry: We can move editorial issues to a later CR revision.

Glenn: When we go to CR we have to list Exit Criteria and any At Risk features. Since at risk
... features may be removed, we may make substantive changes after "WR" (working draft for wide review).
... Most TTML1 issues have equivalents in TTML2 also so we should be able to tackle them together.

nigel: Looking at time, we have many TTML issues and a more limited set of IMSC ones.

Pierre: I'm confident we can deal with all the IMSC topics in 4 hours.

nigel: Then let's cover those all this afternoon.

Dae: Let's cover TTML1 issues this morning then.

group: General agreement to do TTML1 on day 1 am, IMSC day 1 pm, TTML2 day 2.

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.

nigel: Is this for TTML1?

Andreas: Both TTML1 and TTML2.

nigel: Is there any other business to raise?
... If there's time and interest I could give an update on the live TTML work that we're doing here.

TTML1 Issues

Andreas: I have a short presentation. [goes through slides]
... TTML and XSL-FO
... This is still a draft, so apologies if there are things not 100% correct.
... TTML does not use XSL-FO and makes clear it is not needed for rendering.
... TTML relies on XSL-FO as a conceptual model to define normative presentation semantics.
... First step of rendering is TTML -> ISD -> XSL-FO Doc
... according to the algorithm described in TTML1.
... XSL-FO document is a "result tree".

Glenn: The first step is 1-> many, the next is 1->1.

Andreas: Yes.
... Formatting is similar to HTML to DOM.
... The result tree goes to the object tree; most of it looks the same, but for every character
... you create a new object, an inline area. That may be important for some of what we are doing.
... Phase 2: XSL-FO Doc -> Objectified FO-Tree -> Refined FO-Tree.
... Refinement includes shorthand expansion, mapping of properties, computation of values, whitespace handling, inheritance.
... Phase 3: Refined FO-Tree -> FO Area Tree -> Rendered Content.

Glenn: The FO Area Tree is similar to the CSS Box tree.

Andreas: Exactly, and XSL-FO relates its areas to CSS Boxes so you can see the correspondence.
... The Area tree is an ordered tree, with geometric information for placement of every glyph, shape etc.
... Each FO object could be mapped to an area, e.g. fo:block -> block areas + line areas.
... fo:inline -> inline areas
... fo:character -> glyph area
... It could be that one object creates multiple areas, e.g. multiple inline areas.
... XSL areas do not have "properties" but "traits" in the spec.
... such as padding etc.

Glenn: The distinction between properties and traits: we have this distinction between
... specified value, used value, computed value, actual value etc. and you can think of the
... XSL object properties as being closer to specified or computed values, and the area traits
... as being closer to used values or actual values.
... In XSL you have attributes, properties and traits.
... There are lots of labels applied to different concepts.

Andreas: Area Rectangles have a border rectangle, a padding rectangle and a content rectangle.
... In TTML1 only the Region generates a separate padding rectangle. Others do in TTML2.
... Also in TTML1 we have no border rectangle but we do have one for TTML2.

Glenn: In CSS there is also the margin rectangle.

Andreas: XSL-FO does not have margins but it has space before and space after, which correspond.

Nigel: Can they equally be negative, like CSS margins?

Glenn: I believe so.
... Every area is generated by exactly one object.
... Some objects generate more than one area.

Andreas: Line Areas.
... Some terms need clarifying, that are used in XSL-FO.
... Nominal-requested-line-rectangle. before-edge and after-edge.
... For example a block area with font-size 20px and line-height 25px, then the nominal
... requested line rectangle is 20px and related to the dominant baseline.

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.

Andreas: That's really important. The area tree has a nominal font, and you need to know
... which font is used. Every glyph has an assigned nominal font. The font's font table
... indicates the ascender and descender.

Glenn: For example the block level object like a p might have a font that is "Arial, xxx, yyy"
... and for the purpose of computing the requested line rectangle it will use one of those,
... usually the first one, and it will use the font size that applies to the paragraph. Then when
... you divide the content into spans or inline areas, then each of the characters may end up
... being associated with a different actual font, and those fonts may have different
... altitudes and depths.

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.
... Then the expanded-nominal-requested-line-rectangle includes half-leading, being
... half the difference between the computed value of the line-height property adn the computed value of the
... sum of the ascender and descender.
... Example image, showing expanded nominal requested line rectangle being 2.5px greater
... than the inline one both above and below, so the inline area is 20px (font-size) and the expanded
... area is 25px (line height).

Glenn: This is ยง4.5 of XSL-FO.
... Some of these depend on the line stacking property.

Andreas: I will come back to that.
... Then the Expanded-rectangle of an inline-area has a before-edge and after-edge which
... outside the allocation rectangle by a distance equal to the half-leading, on condition that
... the area's allocation rectangle is normal-allocation-rectangle.

Glenn: We need to add support for line-height on span in TTML2 for Ruby.

Nigel: we have an issue for that already.

Glenn: It's #131.
... Also we now have padding and border on span in TTML2 so the large allocation rectangle
... may have to take into account the padding and border on inline areas.

Andreas: Yes it gets more complicated in TTML2.
... Expanded-rectangle: shows slide with an expanded rectangle for each character.

Glenn: For inline content, there's a major question how to define the bpd.
... I'm not sure it is exactly ascender + descender; in CSS it is certainly not specified.
... One way to expand the content rectangle to avoid gaps is to specify the content bpd.
... Another way is some kind of automatic computation of padding and then use the expanded
... rectangle, in other words "auto padding" but that would have to intersect with how we
... use manual padding in TTML2.

Andreas: That's true. Coming back to the conceptual points...
... Line areas and line-stacking-strategy.
... Line stacking strategy has to be defined, and has different values. TTML explicitly
... specifies "line-height" which means the allocation rectangle is the per-inline-height-rectangle.
... We know what that is: its extent in the block progression dimension is the minimum required
... to enclose the expanded-nominal-requested-line-rectangle and the expanded-rectangles
... of all the inline-areas stacked within the line-area.
... This may vary depending on the descendants of the line-area.

Glenn: That can mean that different lines with the same line height and font size can have
... different bpd depending on the padding and border - that's not an issue in TTML1.

Andreas: This applies also to all descendants of the line area, not just the direct children.
... Example with an inline area that has a bigger font size of the block area, which expands the
... line's size in the block progression dimension, for the whole line.

Glenn: The baseline position within the whole line area may go up or down depending on
... the font of the largest character area - it may have a different altitude:depth ratio than the
... other character areas.

Pierre: So with this strategy you are not guaranteed to get the line-height that is requested.

Andreas: Correct, if a p has line-height 25px and one of its descendants has a line-height 40px
... then the actual line-height would be 40px.

Glenn: If we used a different line stacking strategy then you could end up with glyphs on
... one line overlapping glyphs on adjacent lines.
... [shows examples]
... First example shows how larger font size spans in a line can extend the line height.
... Second example shows a nested span where the parent has (non-inheritable) background color of green,
... and child has larger font size than the line height, and result is that the green is only painted
... with the height of the parent p element's specified line-height but the glyph areas are larger.

Nigel: Does this provide guidance for how we solve the issue of gaps between background areas behind adjacent lines?

Andreas: It shows how complex this is!

Glenn: You can't simply increase the height, you also need to keep the baseline consistent.

Andreas: I will make these slides available, but may need to adjust them a little first.

Nigel: One key point from this is that the actual rendering depends on the font chosen at
... rendering time, which is not necessarily known at authoring time.

Glenn: One thing that is useful is to use tools that can show the calculated areas, which many browsers do in developer mode.

Andreas: In FOP you can export the area tree, which is useful.

Glenn: TTPE generates an area tree and hands it off to a renderer.

Nigel: Let's move to the TTML1 issues labelled "bug":

-> https://github.com/w3c/ttml1/issues/221

Glenn: Basically the question is whether padding is inside or outside the extent of the region.
... I have no doubt that the intention in TTML1 was that it would be inside not outside.
... So it would make no sense to define padding or border otherwise. What we may not have

<scribe> .. done very well is how we specified the mapping to XSL-FO. If we had specified it as mapping

UNKNOWN_SPEAKER: to a pair of outer and inner block container, with the inner one having the padding or border
... on it then there would have been no problem here.

nigel: So we are all agreed there is a problem with the spec, and the resolution is a change
... to the mapping to XSL-FO?

Glenn: The mapping to XSL-FO tries to be normative so this is substantive.

Pierre: The text is clear in TTML that it says it is inset, but the confusion is caused by the
... reference to terms used also in XSL-FO such as padding and border, where there is not
... a 1:1 correspondence in fact.

Andreas: We should try to keep the correspondence if possible.

Pierre: Does anybody disagree with the interpretation is that padding does not extend the
... extent of the region?

Andreas: The problem is if I had to decide right now I would make it the same as XSL-FO.
... This is likely different from the intent of the spec though.

Glenn: [Describes proposal with an inner and outer block, using whiteboard]

Pierre: Mapping to HTML and CSS you would not have two divs though.

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.

Pierre: So you use the layout engine to avoid calculating the adjusted extent having subtracted padding?

Glenn: Yes.

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.

Pierre: We all seem to be agreed on the desired outcome, so someone can take the task to
... find a solution that works.

Nigel: With a fiddle or a codepen etc...

Pierre: Exactly.

Glenn: I think we have agreement on the intended results, so it's for me to find a solution unless someone wants to volunteer?

Andreas: I can do that.

Glenn: I don't want to change it so it maps the outer region to a content rectangle.

Andreas: I will aim to do this by beginning of Feb.

nigel: I've added a note to the issue.

-> https://github.com/w3c/ttml1/issues/216

nigel: Process [construct intermediate document] prunes "set" elements. #216

Glenn: That's clear, assign it to me and give it a 3rd edition milestone.

nigel: I've added a note and a milestone to the issue.

-> https://github.com/w3c/ttml1/issues/206 Use of 'em' units in tts:fontSize on region element is not well defined. #206

group: Discusses and agrees proposal to make 1em be the same as 1c which is the same as 100%.

-> https://github.com/w3c/ttml1/issues/227 Should tts:direction apply only to <span>? #227

Pierre: I want to decide if this is a bug.
... I discovered that in XSL tts:direction only applies to inline areas and that writing mode sets
... the block level element direction, and this seems to be different to how CSS behaves.

nigel: Do we think it's a bug?

Pierre: I think it's a bug because it will lead to unexpected behaviour in implementations as it is.

Andreas: It is really hard to see the dependencies between direction and writingMode. There's not much text in it.

Glenn: It relies on the semantics in XSL.

Pierre: That's fine, and in XSL it states that direction does not apply to block level elements
... so it should not apply to p in TTML, and if we make that change then it fixes it in HTML too.

Dae: Or you could make tts:direction on a p really change XSL writing-mode?

Glenn: No, only region should have writing-mode. Direction only applies to inline bidi functionality.

Pierre: That was my conclusion too.

Glenn: In the special case of p direction specifies the default writing mode, which is in XSL but it's
... in a different place where the bidi algorithm is covered.
... Notes that there is already a resolution to this in TTML2 for https://github.com/w3c/ttml2/issues/142

Pierre: [tries that solution out using an IRT test vector]

Andreas: Maybe we need to come back to this later.
... I'm not clear why writing mode is inheritable in XSL but not in TTML.

Glenn: In fact in implementations its effect is inherited because in every implementation you
... need to be able to say for any given area what its writing mode is, and that is answered by
... looking at the writing mode.

Pierre: References XSL that maps writing mode to direction, but the relationship of this to TTML interpretation of direction is unclear.

Glenn: I'm glad that you've raised the other issue, what to rl and lr mean in a vertical writing mode?

-> https://www.w3.org/TR/2006/REC-xsl11-20061205/#direction 2nd bullet in XSL modifications to the CSS definition

-> https://www.w3.org/TR/2006/REC-xsl11-20061205/#compcorr

Andreas: the above maps the start and end values.

Pierre: okay that should work.

Nigel: So is there anything left to do on the issue?

Glenn: I don't think there's a bug here but some clarification notes could be valuable.

Andreas: I think it's really hard for implementers right now to understand the interaction between
... direction and writingMode.

-> https://github.com/w3c/ttml1/issues/219 Step does not apply to textDecoration. #219

-> https://github.com/w3c/ttml2/issues/219 (same issue in TTML2)

Pierre: I think the intent is that each component should be inherited separately.

Glenn: In CSS there are shorthand and longhand properties; we don't have that.
... In CSS the shorthands map to longhands and the inheritance applies at the longhand level.

Nigel: Where longhand is each property separately specified?

Glenn: That's right.
... So we need to note that inheritance is intended to occur in the same fashion here,
... without introducing the longhand properties.

group: Agreed action to be taken, added note to issue.

-> https://github.com/w3c/ttml1/issues/218 Use of cell metric in tts:textOutline. #218

-> https://github.com/w3c/ttml2/issues/217 (equivalent in TTML2)

Nigel: We've discussed and agreed this for TTML2 so just need to note that on the TTML1 issue.
... Same for TTML1 #215 -> TTML2 #200.

-> https://github.com/w3c/ttml1/issues/214 Clarify the semantics of tts:fontSize="2em". #214

nigel: This is related to #206 that we discussed and agreed earlier.

Pierre: It is not clear that em units on font size are relative to the parent element's font size.

Glenn: I think it does say this by reference to XSL-FO which in turn references CSS.

Nigel: I've added a note to the issue and also to https://github.com/w3c/ttml2/issues/216

-> https://github.com/w3c/ttml1/issues/205 Clarify meaning of percentage with writing mode relative edge terms in tts:padding. #205

Nigel: This is a sparse issue report!

Glenn: It's also logged in TTML2 as https://github.com/w3c/ttml2/issues/144

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?

Pierre: The current text may be surprising but it is not ambiguous. I would not change anything.

Glenn: I agree there's no technical change needed just a note to clarify.

Pierre: Here the width and height of the region are independent of the writing mode.

Nigel: So they are just the first and second component of the tts:extent of the region.
... Let's break for lunch - I think we have a few more TTML1 issues to run through.
... Going through remaining issues.

-> https://github.com/w3c/ttml1/issues/197 The [Construct Intermediate Document] process erroneously prunes empty <br> elements. #197

nigel: Added notes to the issue

-> https://github.com/w3c/ttml1/issues/194 Ambiguous definition for determination of descendant region identifier. #194

glenn: Can we come back to this in the morning?

Nigel: Yes, marking as a bug for now.

-> https://github.com/w3c/ttml1/issues/193 Inconsistent implicit duration of singleton span in sequential container. #193

Glenn: I want to mark this as a bug until I prove it isn't one.
... But I need time to review it. I have already done this in TTML2.

Pierre: I implemented this in imscjs as all anonymous spans that are children of seq timeContainers have implicit duration of zero.

Nigel: I've marked it as a bug and added a note that we need to come back to it.

-> https://github.com/w3c/ttml1/issues/196 Handling forward interoperability of attribute extensions in TT namespaces. #196

Nigel: I think this has a potentially big impact since we want to be able to add attributes in
... existing namespaces and have TTML1 processors that do not understand those attributes
... prune them out.
... Okay, I've updated the issue.

-> https://github.com/w3c/ttml1/issues/220 Computed value of lineHeight and inheritance. #220

Pierre: This needs to be fixed.
... I think we have agreed that the "normal" value should be inherited before calculating the computed value.

Nigel: Agreed.
... I've updated the issue.

<mike> good mornong/afternoon


-> https://www.w3.org/wiki/TimedText/F2F-jan-2017#Specification_Topics

Pierre: The scope: IMSC v.next is urgent modifications to IMSC1 that do not result in existing IMSC1 implementations to be non-conformant.
... We got a number of responses by liaison.
... Start with ATSC - they said they have nothing to add.
... ARIB said something similar, and said they are interested in TTML2.

Nigel: I just want to come back to the scope description. I think it's ambiguous what the
... existing IMSC1 implementations shall remain conformant to: I would say that they shall
... remain conformant to IMSC1, but not necessarily IMSC 1.1

Pierre: That's not what I understood and not what I could accept - IMSC 1 processors have
... to remain conformant against any short term update IMSC 1 specification. That means
... that any new features have to be defined with SHOULDs rather than SHALLs.

Nigel: Okay in that case we cannot get consensus on any features with SHALL requirements
... even for IMSC 1.1 processors, and even though IMSC 1 processors would ignore the newly
... introduced syntax.

Mike: Ideally for me we would not introduce any new features at all, but if we recognise that
... some features will be done anyway then it's better to have them all specified in the same
... way rather than multiple syntaxes for the same semantic.

Andreas: I would second Pierre's and Mike's view that we should not introduce new normative
... SHALL requirements that would cause IMSC 1 processors non-conformant to IMSC 1.next.

Dae: I think that makes sense.

Pierre: I would move all normative requirements to IMSC 2.

Glenn: Are we aiming for a second edition or a 1.1?

Pierre: I think that would depend on what changes need to be made.

Thierry: The process is the same, if you bring new features you have to go through CR.

Pierre: The class of changes here would not affect conformance.

Thierry: It says "substantial" changes so we need to look at that in more detail.

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.

Pierre: I think adding an extra document makes it harder for people to find the specification.

Nigel: I thought about that too and also would prefer a single complete IMSC 1.next document
... whether it is a 1.1 or a second edition.

Glenn: There is always the option of a limited scope additional document as a stop-gap, which
... could only be a few pages long and would be easier to get through the process.

Thierry: I would propose to go for a Proposed Edited Recommendation or something like that,
... with a backup to create a new WG Note or something like that.

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.

Glenn: Yes it would.

Pierre: How could that be?

Nigel: Even if it's only a SHOULD then there's a thing with a defined behaviour that is a feature.
... Just to clarify, are you also saying that there would not be a new short code for an IMSC 1.next profile, so that
... processors cannot be distinguished based on support for any newly introduced features?

Pierre: Yes.

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.

Pierre: Let's look at the DVB one then.
... there are issues already raised for that.
... HbbTV next.

Mike: From a private conversation I understand that the HbbTV expectation was not that we would reproduce their existing processor requirement.

Nigel: Yes, that's my understanding too.

Pierre: SMPTE next.

Nigel: Ok that's all the liaisons, to summarise, we have requests for two features, which
... Pierre has already created issues for. Let's look at them in turn:

Pierre: Actually there are a number of issues we can quickly close including those.

-> https://github.com/w3c/imsc/pull/192 addresses four issues:

-> https://github.com/w3c/imsc/issues/178 Highlight semantics of smpte:backgroundImage #178

-> https://github.com/w3c/imsc/issues/188 Example 4 typo - extent height #188

-> https://github.com/w3c/imsc/issues/189 Example 10 - fontHeight problem #189

-> https://github.com/w3c/imsc/issues/190 "green" is not quite green #190

<glenn> https://www.w3.org/2013/09/ttml1-changes.html

group: [reviews PR] Nigel approves and merges.

-> https://github.com/w3c/imsc/issues/194 #zIndex feature is permitted but not used #194

-> https://github.com/w3c/imsc/pull/197

nigel: I made a request for a change.

-> https://github.com/w3c/imsc/issues/184 Potential conflict with respect to pixel aspect ratio. #184

Pierre: there's a pull request for this at https://github.com/w3c/imsc/issues/193

Nigel: Okay, we reviewed that and approved and merged.

-> https://github.com/w3c/imsc/issues/195 Control background between adjacent lines #195

Mike: Is it computationally possible to derive the padding needed to make sure background areas don't have gaps?

Nigel: We reviewed this partially this morning with Andreas's presentation. Our conclusion is
... that at authoring time it is not possible in general to compute the required padding values,
... even if we had a mechanism in TTML1 to specify those padding values.

Andreas: In limited circumstances with XSL-FO conformant implementation and accurate
... knowledge of the font used then it may be possible.

Glenn: I'm not convinced about that and certainly CSS implementations are not consistent.

Andreas: Going back to what kind of information is needed, you need the ascender and
... descender of the font to get the content rectangle height.

Glenn: In the implementation area this is a problem because this could be on a per glyph
... basis or a per glyph run basis, and what if there are multiple fonts on that run.

Andreas: The background is not inherited, and always applies to a span.

Glenn: The algorithm for determining the height of the span does take into account the
... question of ascender and descender of both the paragraph's font and the font of each
... individual glyph area for the inline area in question.

Nigel: We cannot add padding to span in TTML1 anyway.

Pierre: That could be one possible solution.

Glenn: It would not be adequate or reliable enough to achieve the desired results.

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.

Andreas: I do not think we can use any TTML syntax to close the line gaps. The author has
... no tool that they can use, but we can use concepts that already exist, and base new
... syntax on existing tools like padding at rendering time, with a defined mapping to a conceptual model.

Glenn: That raises the other issue - even if we were to define a new style property that allows
... us to define the area, it would leave us with the open problem of mapping to other
... formatting systems where there is no support for this function, like CSS.

Nigel: It depends how complex a mapping we are willing to accept. I believe we could
... do this by using a combination of HTML, CSS and JS to query the content rectangle at
... presentation time and add padding to it.

Andreas: [shares presentation] There is no way to specify a background colour for a line
... area in XSL-FO. There is no trait for it. So what you want to do is have the background
... of each glyph area to the line height.

Glenn: It's easy enough to define a style attribute on the p element that affects the background
... height of the inline areas generated from the descendant spans.

Nigel: I was heading in that direction too.

Glenn: But from this CSS rendering view it might be difficult to implement. I take your point you could do it with JS.

Andreas: There may be a difference between XSL-FO and CSS. It's not really the normative
... reference but it helps to explain how this may work in CSS.
... If you know the content area then you can add padding to before and after edges to achieve the desired outcome.

Pierre: Yes, to implement this you would have to create many different spans and check the
... padding to apply to them each individually. For example you could create a span per character.

Nigel: I think we need to be clear what the requirement is here. I think the simplest thing
... would be a boolean flag that says "do it as now" or "extend in the block progression direction
... the background so that the before edge of each glyph's background coincides with the line area's before edge
... and the after edge coincides with the line area's after edge".

<glenn> https://github.com/w3c/ttml2/issues/150#issuecomment-192490492

Mike: Perhaps a brute force way would be to use regions, but I understand that would have
... a different effect.
... Another is if we need to worry about images too. If the PNGs are all the same height or
... width it all works out, but if they're not, say because the font size changes midline, then
... what do you want it to look like.

Dae: The background colour on a region won't work because the positioning wouldn't work.
... The gap between regions can not be guaranteed.

Glenn: I proposed a bpdContent attribute for inline elements with values like bpdLine.
... There is a slight problem with making bpd on span make it an inline block, but I've been
... considering separating that and specifying display separately anyway.

Nigel: That would solve an issue I opened too, I think it's a good idea.

Andreas: Changing the content rectangle size might have other effects on line stacking etc.
... The question for me is if we can stick to something similar to what Nigel wrote, saying
... "this is what we expect, good luck" or is we need to go deeper and explain more about how
... to implement it. I'm not sure if we can do the second one.

Nigel: I'm not sure if we need to do the second one.

Glenn: One benefit of my approach is that we could propose it as a solution to the CSSWG.

Pierre: Based on what I've heard the simplest thing is a boolean style attribute that signals
... the authorial intent, which we can add to IMSC1, then hopefully in the scope of IMSC2
... and TTML2 then we can interface with the CSS folks and come up with something better.

Glenn: Can we make it a boolean switch on the root element?

Nigel: I don't understand why you'd make a style-affecting semantic have syntax in the parameter namespace.

Glenn: It's a lot easier to add new parameter attributes to my implementation than a new style attribute.

Nigel: Even the HbbTV heuristic allows for different presentations for different content in the same ISD, since it is based on the specified lineHeight

Andreas: To make it applicable document wide you could use the styling namespace and make
... it like tts:extent and say it applies to p but only is significant on the tt element.

Nigel: It seems like we are converging on this boolean approach.

Pierre: I think we just need to pick one.

Nigel: I would pick a style attribute that is inheritable and applies to p.
... I think the namespace has to be itts.

Pierre: This can vary on different p elements.

Andreas: +1.

Pierre: Yes.

Nigel: I suggested a name "padToLine"

Glenn: I hate "pad"

Andreas: Something like "extendBackgroundToLine" works okay because it just talks about the background.

Nigel: "fillLineGap"?

Pierre: okay let's do that.

Glenn: Values are true or false?

Pierre: Yes
... Can we make it clear this is a SHOULD?

Nigel: We can make support for the feature optional but say that processors that do support it shall do it in a specified way.

Glenn: I suggest strongly that this is defined in a separate Note.

Nigel: While we consider this I have added a note to the issue.

Pierre: Thierry, can a Second Edition introduce new functionality, in your experience?

Thierry: If you ask anyone they will say its a case by case discussion with the Director.
... A few years ago I would say no chance, but nowadays I'm not sure.

Nigel: Why don't I take an action to chat to Wendy?

group: [discussion continues]

TTML Profiles document

Mike: I resolved all the issues, created a pull, merged it, and walked you through it. So
... folks were given until today to comment on it before we publish it. Does anyone have
... any comments or concerns over the current document in github?

-> https://w3c.github.io/tt-profile-registry/

PROPOSAL: Publish the TTML Media Type Definition and Profile Registry as updated at https://w3c.github.io/tt-profile-registry/

RESOLUTION: We will publish the TTML Media Type Definition and Profile Registry as updated at https://w3c.github.io/tt-profile-registry/

<scribe> ACTION: tmichel Publish the updated TTML profile registry at https://w3c.github.io/tt-profile-registry/ by 2017-01-19 [recorded in http://www.w3.org/2017/01/12-tt-minutes.html#action01]

<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].


Pierre: I want to go back to the idea of specifying an optional feature support.
... You would add a new category to prohibited and permitted that would be, say, optional.
... That's your proposal Nigel?

Nigel: Yes. The difference between that and a should in a semantic specification is that if
... supported it is clear what is mandated, but support is optional, as opposed to both
... support being optional and the semantic being optional if supported.
... This would add a new category to section 4.

Pierre: Okay I'll recast the pull request in that way and see what it looks like.

-> https://github.com/w3c/imsc/issues/198 recommendation for "end" but not "dur" #198

Pierre: IMSC 1 tries to help the author by recommending that begin and end attributes should always be specified for timing.
... Mike you pointed out that begin and dur is not recommended even though it is also unambiguous.
... The question is should the recommendation be removed or changed to permit begin and dur?

Mike: Yes, also it wasn't clear what this recommendation is for. I took it initially to mean you
... shouldn't have indeterminate begin or end times. If there's another purpose it should be noted.


<trackbot> issue-382 -- Require a computed non-indefinite begin time -- closed

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/382

Mike: This causes a problem because validators issue warnings when dur is used instead of end even though it's actually fine.

Glenn: The recommendation is a reasonable constraint if you are also trying to create a conformant EBU-TT-D document.

Dae: We should just add the possibility of a dur attribute as an alternative to end.

Pierre: What's your thought on that proposal?

Mike: Can you have both end and dur?

Nigel: Yes but I think that's worth issuing a warning for!

-> https://github.com/w3c/imsc/issues/191 Add parameter signaling the editorial area of a document instance #191

Pierre: IMF has activeAreaRectangle which is named like that to be symmetric with other MXF terms.
... "activeAreaRectangle 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."

Glenn: I'm fine with activeArea and maybe informatively reference IMF for derivation purposes.

Pierre: The spec is SMPTE 2067-2:2016 Annex H.

Nigel: We need to clarify that normally the whole root container region is shown and only
... in exceptional circumstances might that be cropped, but in that case the activeArea should
... be shown in its entirety.

Pierre: We should definitely clarify that.

Mike: Why do we need to tell anyone that they have to display the captions that are there?
... I think the bounding rectangle is a really good idea. My problem is with directing or
... forbidding certain rendering behaviour. I just don't get it.

Andreas: So you would not recommend any presentation processor behaviour?

Mike: That's correct.

Andreas: That leaves it up to others to define it.

Glenn: It would be a no-op if we did not define the purpose of it.

-> https://github.com/w3c/imsc/pull/196

Pierre: Can you propose an edit to take into account your review comment 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.

Mike: As it stands this looks okay from a normative perspective - I cannot see any shoulds, shalls or mays.

Day 1 close

nigel: Thanks everyone, we've had a really full day and tackled a lot of issues! [adjourns meeting day 1]

Summary of Action Items

[NEW] ACTION: tmichel Publish the updated TTML profile registry at https://w3c.github.io/tt-profile-registry/ by 2017-01-19 [recorded in http://www.w3.org/2017/01/12-tt-minutes.html#action01]

Summary of Resolutions

  1. We will publish the TTML Media Type Definition and Profile Registry as updated at https://w3c.github.io/tt-profile-registry/
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/01/12 18:26:23 $