- From: Thierry MICHEL <tmichel@w3.org>
- Date: Mon, 16 Jan 2017 08:45:04 +0100
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>, Timed Text Working Group <public-tt@w3.org>
Thank you Nigel for scribing and hosting this F2F in London. and for linking the minutes from the wiki. https://www.w3.org/wiki/TimedText Thierry. Le 13/01/2017 à 18:52, Nigel Megitt a écrit : > Thanks to everyone who was able to make it to, or join, the London face > to face meeting that has just concluded. We met some of our goals and > came up with good plans for the remainder. > > Minutes are available in html format at: > > Day 1: https://www.w3.org/2017/01/12-tt-minutes.html > Day 2: https://www.w3.org/2017/01/13-tt-minutes.html > > We made 2 resolutions: > > *RESOLUTION: We will publish the TTML Media Type Definition and Profile > Registry as updated at https://w3c.github.io/tt-profile-registry/* > *RESOLUTION: We will impose a cut-off for new TTML2 features of > Wednesday 15 Feb 2017.* > * > * > The review period under our Decision Policy for the first one ends on > Thursday 26th January and for the second on Friday 27th January. > > Note that some decisions are recorded in their relevant GitHub issues > rather than being detailed in the minutes. > > Minutes in text format: > > [1]W3C > > [1] http://www.w3.org/ > > Timed Text Working Group Teleconference > > 12 Jan 2017 > > See also: [2]IRC log > > [2] http://www.w3.org/2017/01/12-tt-irc > > Attendees > > Present > Pierre, Andreas, Glenn, Thierry, Nigel, Dae, Mike > > Regrets > Rohit > > Chair > Nigel > > Scribe > nigel > > Contents > > * [3]Topics > 1. [4]Agenda > 2. [5]TTML1 Issues > 3. [6]IMSC > 4. [7]TTML Profiles document > 5. [8]IMSC > 6. [9]Day 1 close > * [10]Summary of Action Items > * [11]Summary of Resolutions > __________________________________________________________ > > <scribe> scribe: nigel > > Agenda > > 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": > > -> [12]https://github.com/w3c/ttml1/issues/221 > > [12] 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. > > -> [13]https://github.com/w3c/ttml1/issues/216 > > [13] 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. > > -> [14]https://github.com/w3c/ttml1/issues/206 Use of 'em' > units in tts:fontSize on region element is not well defined. > #206 > > [14] https://github.com/w3c/ttml1/issues/206 > > group: Discusses and agrees proposal to make 1em be the same as > 1c which is the same as 100%. > > -> [15]https://github.com/w3c/ttml1/issues/227 Should > tts:direction apply only to <span>? #227 > > [15] https://github.com/w3c/ttml1/issues/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 [16]https://github.com/w3c/ttml2/issues/142 > > [16] 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? > > -> [17]https://www.w3.org/TR/2006/REC-xsl11-20061205/#direction > 2nd bullet in XSL modifications to the CSS definition > > [17] https://www.w3.org/TR/2006/REC-xsl11-20061205/#direction > > -> [18]https://www.w3.org/TR/2006/REC-xsl11-20061205/#compcorr > > [18] 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. > > -> [19]https://github.com/w3c/ttml1/issues/219 Step > 10.4.4.2(6)(a) does not apply to textDecoration. #219 > > [19] https://github.com/w3c/ttml1/issues/219 > > -> [20]https://github.com/w3c/ttml2/issues/219 (same issue in > TTML2) > > [20] https://github.com/w3c/ttml2/issues/219 > > 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. > > -> [21]https://github.com/w3c/ttml1/issues/218 Use of cell > metric in tts:textOutline. #218 > > [21] https://github.com/w3c/ttml1/issues/218 > > -> [22]https://github.com/w3c/ttml2/issues/217 (equivalent in > TTML2) > > [22] https://github.com/w3c/ttml2/issues/217 > > 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. > > -> [23]https://github.com/w3c/ttml1/issues/214 Clarify the > semantics of tts:fontSize="2em". #214 > > [23] https://github.com/w3c/ttml1/issues/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 > [24]https://github.com/w3c/ttml2/issues/216 > > [24] https://github.com/w3c/ttml2/issues/216 > > -> [25]https://github.com/w3c/ttml1/issues/205 Clarify meaning > of percentage with writing mode relative edge terms in > tts:padding. #205 > > [25] https://github.com/w3c/ttml1/issues/205 > > Nigel: This is a sparse issue report! > > Glenn: It's also logged in TTML2 as > [26]https://github.com/w3c/ttml2/issues/144 > > [26] 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. > > -> [27]https://github.com/w3c/ttml1/issues/197 The [Construct > Intermediate Document] process erroneously prunes empty <br> > elements. #197 > > [27] https://github.com/w3c/ttml1/issues/197 > > nigel: Added notes to the issue > > -> [28]https://github.com/w3c/ttml1/issues/194 Ambiguous > definition for determination of descendant region identifier. > #194 > > [28] https://github.com/w3c/ttml1/issues/194 > > glenn: Can we come back to this in the morning? > > Nigel: Yes, marking as a bug for now. > > -> [29]https://github.com/w3c/ttml1/issues/193 Inconsistent > implicit duration of singleton span in sequential container. > #193 > > [29] https://github.com/w3c/ttml1/issues/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. > > -> [30]https://github.com/w3c/ttml1/issues/196 Handling forward > interoperability of attribute extensions in TT namespaces. #196 > > [30] https://github.com/w3c/ttml1/issues/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. > > -> [31]https://github.com/w3c/ttml1/issues/220 Computed value > of lineHeight and inheritance. #220 > > [31] https://github.com/w3c/ttml1/issues/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 > > IMSC > > -> > [32]https://www.w3.org/wiki/TimedText/F2F-jan-2017#Specificatio > n_Topics > > [32] 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. > > -> [33]https://github.com/w3c/imsc/pull/192 addresses four > issues: > > [33] https://github.com/w3c/imsc/pull/192 > > -> [34]https://github.com/w3c/imsc/issues/178 Highlight > semantics of smpte:backgroundImage #178 > > [34] https://github.com/w3c/imsc/issues/178 > > -> [35]https://github.com/w3c/imsc/issues/188 Example 4 typo - > extent height #188 > > [35] https://github.com/w3c/imsc/issues/188 > > -> [36]https://github.com/w3c/imsc/issues/189 Example 10 - > fontHeight problem #189 > > [36] https://github.com/w3c/imsc/issues/189 > > -> [37]https://github.com/w3c/imsc/issues/190 "green" is not > quite green #190 > > [37] https://github.com/w3c/imsc/issues/190 > > <glenn> [38]https://www.w3.org/2013/09/ttml1-changes.html > > [38] https://www.w3.org/2013/09/ttml1-changes.html > > group: [reviews PR] Nigel approves and merges. > > -> [39]https://github.com/w3c/imsc/issues/194 #zIndex feature > is permitted but not used #194 > > [39] https://github.com/w3c/imsc/issues/194 > > -> [40]https://github.com/w3c/imsc/pull/197 > > [40] https://github.com/w3c/imsc/pull/197 > > nigel: I made a request for a change. > > -> [41]https://github.com/w3c/imsc/issues/184 Potential > conflict with respect to pixel aspect ratio. #184 > > [41] https://github.com/w3c/imsc/issues/184 > > Pierre: there's a pull request for this at > [42]https://github.com/w3c/imsc/issues/193 > > [42] https://github.com/w3c/imsc/issues/193 > > Nigel: Okay, we reviewed that and approved and merged. > > -> [43]https://github.com/w3c/imsc/issues/195 Control > background between adjacent lines #195 > > [43] https://github.com/w3c/imsc/issues/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> > [44]https://github.com/w3c/ttml2/issues/150#issuecomment-192490 > 492 > > [44] 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? > > -> [45]https://w3c.github.io/tt-profile-registry/ > > [45] https://w3c.github.io/tt-profile-registry/ > > PROPOSAL: Publish the TTML Media Type Definition and Profile > Registry as updated at > [46]https://w3c.github.io/tt-profile-registry/ > > [46] https://w3c.github.io/tt-profile-registry/ > > RESOLUTION: We will publish the TTML Media Type Definition and > Profile Registry as updated at > [47]https://w3c.github.io/tt-profile-registry/ > > [47] https://w3c.github.io/tt-profile-registry/ > > <scribe> ACTION: tmichel Publish the updated TTML profile > registry at [48]https://w3c.github.io/tt-profile-registry/ by > 2017-01-19 [recorded in > [49]http://www.w3.org/2017/01/12-tt-minutes.html#action01] > > [48] https://w3c.github.io/tt-profile-registry/ > [49] http://www.w3.org/2017/01/12-tt-minutes.html#action01] > > <trackbot> Created ACTION-492 - Publish the updated ttml > profile registry at > [50]https://w3c.github.io/tt-profile-registry/ by 2017-01-19 > [on Thierry Michel - due 2017-01-19]. > > [50] https://w3c.github.io/tt-profile-registry/ > > IMSC > > 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. > > -> [51]https://github.com/w3c/imsc/issues/198 recommendation > for "end" but not "dur" #198 > > [51] https://github.com/w3c/imsc/issues/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. > > issue-382? > > <trackbot> issue-382 -- Require a computed non-indefinite begin > time -- closed > > <trackbot> > [52]http://www.w3.org/AudioVideo/TT/tracker/issues/382 > > [52] 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! > > -> [53]https://github.com/w3c/imsc/issues/191 Add parameter > signaling the editorial area of a document instance #191 > > [53] https://github.com/w3c/imsc/issues/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. > > -> [54]https://github.com/w3c/imsc/pull/196 > > [54] 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 > [55]http://www.w3.org/2017/01/12-tt-minutes.html#action01] > > [55] http://www.w3.org/2017/01/12-tt-minutes.html#action01 > > Summary of Resolutions > > 1. [56]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 [57]scribe.perl version > 1.148 ([58]CVS log) > $Date: 2017/01/12 18:26:23 $ > > [57] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [58] http://dev.w3.org/cvsweb/2002/scribe/ > > > [1]W3C > > [1] http://www.w3.org/ > > Timed Text Working Group Teleconference > > 13 Jan 2017 > > See also: [2]IRC log > > [2] http://www.w3.org/2017/01/13-tt-irc > > Attendees > > Present > Pierre, Andreas, Glenn, Thierry, Dae, Nigel > > Regrets > Rohit > > Chair > Nigel > > Scribe > nigel > > Contents > > * [3]Topics > 1. [4]IMSC > 2. [5]Group Actions etc > 3. [6]TTML2 > 4. [7]TTML2 Issues > 5. [8]TTML Issues continued > 6. [9]TTML2 issues and WD review > 7. [10]Group working model > 8. [11]TTML2 issues > 9. [12]Meeting Closure > * [13]Summary of Action Items > * [14]Summary of Resolutions > __________________________________________________________ > > <scribe> scribe: nigel > > IMSC > > Pierre: Returning to the process for publishing an updated > version of IMSC... > ... are there likely to be implementations for the line gap > closing issue? > > group: [conversation about if there's a way to go straight to > PER or go via the traditional WD -> CR -> PR process.] > > nigel: If we are adding any new features then the thing that > could impose the longest duration > ... on the publication process might be the patent policy, and > even if features are completely > ... optional it would be valuable to have them be covered by > this. > > Andreas: For some external organisations to reference the > update it may need to be a Recommendation. > > Glenn: How would industry react to introducing new optional > features in a new version of the spec, given that the current > spec only has required features? > > Nigel: There are two devils to choose between: having some > processors that behave less completely than others, or having > identified processors that actually cannot process new > documents. > ... The view from yesterday is that the second option is less > bad. > > Pierre: Yes, specifically for the two features we are > considering, line gap and active area signalling. > > Nigel: Here's a wiki page on how quickly we could get to an > updated Rec: > > -> > [15]https://www.w3.org/community/w3process/wiki/Rectracktimelin > e > > [15] https://www.w3.org/community/w3process/wiki/Rectracktimeline > > group: [discussion of options for a name for the new spec] > > nigel: Other groups have used 1.01 or Level 1 etc > > Pierre: It's important for industry perception that we have a > single new document that does not give the impression that > existing IMSC1 processors are no longer valid somehow. > > Glenn: It would be easier to publish the new features in a new > Rec track document or WG Note. > > Andreas: It would be better for industry to keep the current > view of the existing profiles. > > Glenn: Some of my clients strongly argue against proliferation > of profiles. > ... Introducing new features without a newly identified process > is antithetical to past practice. > > Nigel: It's worth us pursuing if we can correctly go through > the wide review, implementation, patent policy etc and have an > outcome that is backward compatible with the previous version > but still accessible via the same short name. For example a > 1.0.1 version. > > Glenn: I feel this goes against history and precedence and am > concerned about unintended consequences. > > Thierry: How are you going to justify that you're publishing a > second FPWD of the same short name? > > Nigel: Can we go straight back to CR? > > -> [16]https://www.w3.org/2015/Process-20150901/#rec-edited > > [16] https://www.w3.org/2015/Process-20150901/#rec-edited > > Pierre: I think the fact that we are not changing conformance > because we're only introducing optional conformance means I > think we have a strong case. > > Andreas: We made a substantive change in conformance between > TTML1 and TTML1SE. > > Glenn: We did, but did not introduce any new features. > > Nigel: For me the only question is can we follow last sentence > of process §6.7.2 while using the same short name. > > Pierre: I propose to put together a short presentation > explaining why we want to do this. > ... I will send it to the group. > > Thierry: How long will it take to put a new WD together? > > Pierre: We're just working on last details so end of next week. > > Thierry: It would be useful to have an ED to show to the > Director - that would probably help. > > Pierre: I think we could do this, have no outstanding issues, > show the liaisons, and make the case. > > Nigel: We would need to be careful not to overwrite the exising > /TR/ttml-imsc1/ link so it no longer points to the Rec, > ... for instance by using something like > /TR/2017/FPWD-ttml-imsc1-[date]/ > > Pierre: Can we look at a pull request? > > -> [17]https://github.com/w3c/imsc/pull/199 > > [17] https://github.com/w3c/imsc/pull/199 > > -> Recommend begin+dur in addition to begin+end #199 > > Pierre: For the Unicode liaison, there's no action for us at > this time. > ... Their plan as I understand it is to correct their exemplars > in the light of the submission > ... and in the context of IMSC2 we will adapt the annex based > on the outcome of their edits. > > Nigel: As Chair, looking at the agenda, I think we should come > back to the IMSC 2 scope question in a later meeting. > > Group Actions etc > > Nigel: First up, will we have a F2F meeting at TPAC 2017 in > California? > ... 6-10 Nov in Burlingame. > > group: [approval] > > Glenn: I propose that we reserve 4 days since 2 day meetings > never seem long enough. > ... If we have gone to Rec by May according to our timeline > then we would not need 4 days. > > action-480? > > <trackbot> action-480 -- Thierry Michel to Request schedule > time for horizontal review of ttml2 -- due 2016-09-26 -- > PENDINGREVIEW > > <trackbot> > [18]http://www.w3.org/AudioVideo/TT/tracker/actions/480 > > [18] http://www.w3.org/AudioVideo/TT/tracker/actions/480 > > Thierry: I did ask all the groups. > ... They are starting to review it, but we should tell them > when we have a 'final' document. > > close action-480 > > <trackbot> Closed action-480. > > nigel: I did respond to a request from i18n (Addison) if it > would be okay to delay by a couple of weeks, which I said would > likely not cause us any problems. > > Thierry: Will the next WD of TTML2 be the final WD? > > Glenn: That's a good goal; there are probably around 100 issues > I need to resolve. > > Thierry: Will new features be allowed? > > Nigel: I would look at them on a case by case basis but > generally take a hard line for anything new in TTML2 at this > point. > > Pierre: It's reasonable to tell the world what the deadline for > new features is. > > action-491? > > <trackbot> action-491 -- Nigel Megitt to Generate detailed > (timed) agenda for f2f to allow people to prepare in advance -- > due 2016-12-22 -- OPEN > > <trackbot> > [19]http://www.w3.org/AudioVideo/TT/tracker/actions/491 > > [19] http://www.w3.org/AudioVideo/TT/tracker/actions/491 > > close action-491 > > <trackbot> Closed action-491. > > TTML2 > > <glenn> [20]https://www.w3.org/wiki/TimedText/Publications > > [20] https://www.w3.org/wiki/TimedText/Publications > > Nigel: In terms of roadmap, we still have work to do to > generate a WD for Wide Review, > ... so we're behind what's currently on that publications page > link by some months. > > Glenn: The quickest we could get to a WD including updated spec > text would be the end of February, addressing all open issues, > at least to the point where there's something in the spec. > ... If we start a wide review in early March, then we need a > review period. 60 days? > > Thierry: 30 days? > > Nigel: I would be conservative and choose 60 days. > > Andreas: +1 > > Thierry: Can we focus the request for wide review on the new > features in TTML2? > > Glenn: We can point to the annex of changes, but anyone can > comment on anything they want. > ... Wide Review would then be completed in early May, and we > need to respond to comments. > > Nigel: I would give that 6 weeks at least. > > Pierre: Responding to dispositions can take some time because > it involves the reviewers too. > > Andreas: Or 8 weeks. > > Glenn: I would say 8 weeks/2 months too. > > Thierry: We can start addressing comments early if there are > comments. > > Glenn: We're up to end of June, beginning of July for CR. > > Dae: There should be implementations by then I think. > > Glenn: What's the shortest CR period? > > Nigel: 1 month, as long as there are implementations. > > -> [21]https://www.w3.org/2015/Process-20150901/#last-call > > [21] https://www.w3.org/2015/Process-20150901/#last-call > > Nigel: The process tells us the CR should be longer than 4 > weeks for complex documents, which I would argue does apply to > TTML2. > > Glenn: We need to create test suites too. > > Nigel: They need to be in the exit criteria, so they should be > there before CR. > > Glenn: We can define the test suite during CR. > > Nigel: I think 8 weeks for CR is reasonable. > ... That means we won't exit CR before September, or it could > be later if we want to wait for > ... more implementations. > > Glenn: At the end of the first CR we have to see where we are > and if we need to make any > ... substantive changes to fix technical errors then we would > need a new CR. Also we have > ... to decide which features to mark as at risk when we publish > each CR. > > nigel: Then PR is at least 28 days. > > Dae: So if everything goes perfectly according to this plan > then it could be a Rec by the end of September? > > Thierry: At best. > > Nigel: One risk is that the CR would be during summer holiday > period. > > Pierre: Another is that we should plan for a second CR, because > the risk of this being needed is significant. > ... I would add another month for that. > > Glenn: In our previous plan we had 4 months for CR1 and 2 > months for CR2. > > Nigel: The timeline we've outlined is quite aggressive for > TTML2. > > Glenn: We have examples for most of the TTML2 features and I'm > sure we'll be augmenting them over time to make them a fuller > set. > ... I expect at least 3 implementations reported, one from > Skynav and 2 from Netflix. > > Dae: We'll have 2. Not necessarily each having all features. > > Nigel: I'm expecting BBC to have at least one implementation of > the audio description work. > > Glenn: We will need to define what counts as an implementation > - just syntactic parsing or both that and presentation > semantics. > > Nigel: We have to have independent implementations. > > Glenn: "independent" is not formalised in W3C. > > Thierry: It's not sharing the same code. > > Glenn: That's one possible interpretation. It's up to us to > define it. > > Pierre: So what deadline for new features should we impose on > ourselves? > > Glenn: I would say mid February to get it into the Wide Review > draft. 15th Feb. > > Andreas: I'm a bit sceptical about this, I think realistically > we are likely to have the open issues closed and a WD for Wide > Review at end of March. > > Glenn: I agree it's more likely, but I would retain 15 Feb as a > deadline for new features. > > PROPOSAL: We will impose a cut-off for new TTML2 features of > Wednesday 15 Feb 2017. > > RESOLUTION: We will impose a cut-off for new TTML2 features of > Wednesday 15 Feb 2017. > > Nigel: I'll highlight that in a minutes email. > > Glenn: Then the question is, solidifying this timeline, do we > want to give ourselves to the end of March for the Wide Review > WD? > > Nigel: Let's say 15th March for all issues to be discussed and > agreed, or deferred, and then > ... 30th March for the final editorial version of the WD for > Wide Review. > > Andreas: +1 > > Glenn: OK > > Nigel: Please could you create an updated picture Pierre? > > Pierre: Yes > > <scribe> ACTION: pal Update timeline picture to reflect new > TTML2 publication timeline [recorded in > [22]http://www.w3.org/2017/01/13-tt-minutes.html#action01] > > [22] http://www.w3.org/2017/01/13-tt-minutes.html#action01] > > <trackbot> Created ACTION-493 - Update timeline picture to > reflect new ttml2 publication timeline [on Pierre-Anthony > Lemieux - due 2017-01-20]. > > Action-493: WD for Wide Review 30th March, Wide Review 8 weeks, > Comment Resolution 8 weeks then CR1 for min 8 weeks, then CR2 > for 4 weeks, then PR for 4 weeks, then Rec. > > <trackbot> Notes added to Action-493 Update timeline picture to > reflect new ttml2 publication timeline. > > action-493? > > <trackbot> action-493 -- Pierre-Anthony Lemieux to Update > timeline picture to reflect new ttml2 publication timeline -- > due 2017-01-20 -- OPEN > > <trackbot> > [23]http://www.w3.org/AudioVideo/TT/tracker/actions/493 > > [23] http://www.w3.org/AudioVideo/TT/tracker/actions/493 > > Pierre: The next question is when should the FPWD of IMSC2 be? > > Nigel: I think we should be preparing it during the TTML2 WD > for Wide Review period. > > Pierre: Yes, though we need clear requirements and may be busy > with IMSC 1 v.next > ... End of July for a FPWD is not too unrealistic. > > Nigel: By the way the deadline for new features is scoped to > the WD for Wide Review. > > Andreas: The requirements capture for IMSC 2 may generate new > features for TTML2. > > Pierre: That's a good point. Comments in by end of May is > reasonable, which could be drivers for new features in TTML2. > > Dae: Would a F2F help deliver this aggressive timescale? > > Glenn: It may be useful to have one to help dispose of the > comments, perhaps in May/June. > > Dae: It would give us a chance to review any IMSC 2 > requirements or feedback too. > > action-493: Pierre has posted the updated picture at > [24]https://www.w3.org/wiki/TimedText/Publications > > [24] https://www.w3.org/wiki/TimedText/Publications > > <trackbot> Notes added to action-493 Update timeline picture to > reflect new ttml2 publication timeline. > > close action-493 > > <trackbot> Closed action-493. > > group: No schedule that works for a summer F2F to be useful; > informal meetings are a possibility for those who can make > them. > > TTML2 Issues > > Pierre: We said we would come back to a couple of TTML1 issues. > > Dae: 193 and 194. > > -> [25]https://github.com/w3c/ttml1/issues/194 Ambiguous > definition for determination of descendant region identifier. > #194 > > [25] https://github.com/w3c/ttml1/issues/194 > > Glenn: There was a question here about what the requirement > should be. > ... One question is does what is in TTML1 have an unambiguous > behaviour regardless of whether it is intended or not. > > nigel: [lunch] > > TTML Issues continued > > -> [26]https://github.com/w3c/ttml1/issues/193 Inconsistent > implicit duration of singleton span in sequential container. > #193 > > [26] https://github.com/w3c/ttml1/issues/193 > > Nigel: I've added a note to the issue. We need to resolve this > for TTML2 as well. > > Glenn: I need to investigate more, I'm not prepared to close > today. > > Nigel: I really would not mind marking this as Wontfix and > leaving the existing behaviour in place unchanged. > ... It's a corner case that does not seem to cause any > significant issues. > > Glenn: I agree it's a corner case. > > TTML2 issues and WD review > > Nigel: Firstly, where there are TTML1 issues that we've > discussed and agreed is everyone happy for me to mark the TTML2 > equivalents as Discussed and Agreed offline? > > Andreas: Yes > > Glenn: [nods] > > Pierre: Absolutely. > > <scribe> ACTION: nigel Mark the TTML2 issues as Discussed and > Agreed where we've discussed and agreed their equivalent TTML1 > issues. [recorded in > [27]http://www.w3.org/2017/01/13-tt-minutes.html#action02] > > [27] http://www.w3.org/2017/01/13-tt-minutes.html#action02] > > <trackbot> Created ACTION-494 - Mark the ttml2 issues as > discussed and agreed where we've discussed and agreed their > equivalent ttml1 issues. [on Nigel Megitt - due 2017-01-20]. > > Nigel: Now what should we focus on? > > Glenn: I'd like to look at the updated WD > > Andreas: I'd like to look at the spatial positioning annex in > the TTML2 WD and the new text on tts:lineHeight > > Pierre: I'd like to look at the PAR/SAR/DAR recently added > text. > > Nigel: Here's a link to the diff between this WD and the > previous: > > -> > [28]http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.o > rg%2FTR%2F2016%2FWD-ttml2-20161117%2F&doc2=https%3A%2F%2Fwww.w3 > .org%2FTR%2F2017%2FWD-ttml2-20170106%2F#root-container-region-s > emantics > > [28] http://services.w3.org/htmldiff?doc1=https://www.w3.org/TR/2016/WD-ttml2-20161117/&doc2=https://www.w3.org/TR/2017/WD-ttml2-20170106/#root-container-region-semantics > > -> > [29]https://www.w3.org/TR/ttml2/#root-container-region-semantic > s > > [29] https://www.w3.org/TR/ttml2/#root-container-region-semantics > > Glenn: I'd like to go through this draft material and get input > on it. > ... Pierre has already suggested some improvements; I'm not > fixed in my thinking on this yet - I'm open to changes. > > Pierre: My comments were about the algorithm. A bigger point is > I don't think it makes sense > ... to define pixelAspectRatio if the document does not use > pixel dimensions. > ... Similarly what do pixel measurements mean if there is no > tts:extent on the root element? > > Glenn: In TTML1 it was assumed that there were pixels present > regardless of whether tts:extent was specified. Also we did not > have to worry about images. > > Nigel: The definition of PAR jumps into physical units whereas > SAR and DAR are logical. > ... If you're going to do maths on them in the algorithm below > they better be in the same units. > ... In my view all the pixels in TTML are logical. > > Pierre: It's possible to define an internally consistent > logical coordinate space using pixels regardless of the > physical device pixels. > ... You can do that either by explicitly specifying > tt:tt/tts:extent or by providing it in the document processing > context. > ... You can handle images in this context as a separate > activity. > > Glenn: §6.2.7 in TTML1 is the only place where PAR is defined. > > Nigel: There's nothing there that refers to physical device > pixels. > > Glenn: Right. The question is how to define these terms more > fully. > > Pierre: I would define PAR only in terms of DAR and SAR and not > mention anything about logical or physical pixels. > > Nigel: I would like to separate the handling of image sample > pixels from logical TTML pixels, which again are independent of > any subsampling or supersampling to generate device pixels. > > Glenn: We can define PAR is a ratio of DAR and SAR, then the > question is whether to tie that > ... to any physicality or logicality. In the document > coordinate space we are going to say it > ... has a resolution that divides the document coordinate space > into pixels. > > Pierre: You don't need pixels though, so you don't have to > specify these. > > Glenn: I want to though. > > Pierre: For example imscjs defines all dimensions canonically > related to a root container region that extends in each > dimension from 0 to 1, > ... without mentioning pixels at all. > > Glenn: What do you do when you have a pixel-sized image? > > Pierre: In IMSC1 for example the image must be the same size as > the region so you don't > ... care what the pixels in the image are - you're always going > to scale it. > > Glenn: Let's say I'm an author and I have a PNG image with a > phys chunk and I want the > ... rendering engine to display it in however many logical > pixels so that the physical size > ... matches the actual size in the phys chunk. > > Nigel: If I want a particular size I would specify that in > logical coordinates, or if not then I > ... would solely specify a position. I don't know why you'd use > native size in a TTML context. > > Pierre: You would also need to take into account scaling the > root container region. > > Nigel: So we have one issue to handle, the definition of PAR. > > Glenn: What do those here think should happen if no aspect > ratio is specified? > > Nigel: If no aspect ratio is specified then I think DAR may be > provided by the processing context. > > Pierre: That's what IMSC1 does - it says the DAR is the DAR of > the related media object. > ... In TTML2 I think we can leave it undefined. > ... "undefined" has to be a possible value. > > Nigel: I think SAR="undefined" makes sense and implies that > pixel based measures are meaningless. > > Pierre: You could always require that the processing context > defines the DAR if it is omitted. > > Glenn: If no aspect ratio is specified and if there is a > related media object with a DAR then use that. > > Pierre: There may be scenarios where there is a related media > object but the processing context does not want to fill it with > the Root Container Region. > > Glenn: Then we should document that in No Aspect Ratio then the > document processing context is expected to provide a DAR, and > then fall through to One Aspect Ratio. > > Nigel: The DAR is the most important thing because it will > determine how many characters will fit on a line. > > Pierre: +1 > > Glenn: Then I'll remove the default value of PAR. > ... Now look at H.1.2 One Aspect Ratio. If one aspect ratio is > defined... > > Pierre: If no SAR is specified then leave it and PAR > unspecified/undefined. > > Glenn: OK let's run with, if only DAR is specified then SAR and > PAR are left as "undefined". > ... Now what if there's no DAR? That's like in TTML1 having > tts:extent and no ttp:pixelAspectRatio. > > Nigel: Even with "no aspect ratio provided" we just insisted > that the document processing > ... context provide a DAR, so I think we can insist on this. > ... The implication of no DAR is that you'll never write > anything to a display. > > Pierre: That's right, then you can't display anything visually. > > Glenn: Okay I think I get that. > ... Now what if only PAR is specified? > ... I guess you would also require that the processing context > provide a DAR? > > Nigel: Yes > > Glenn: OK then let's go to 2 aspect ratios. > > Nigel: This looks simple enough but what if there is a provided > DAR and it does not match > ... SAR x PAR? That is like the case with ittp:aspectRatio, in > which the root container region has a different shape to the > related media object, and alignment rules are specified. > ... Maybe we need two distinct concepts of the contextual DAR > and the document DAR. > ... In the first two cases they are identical but in the third > one they could be different. > > Glenn: That could use the new term "contains". > > Nigel: "Contain" as a semantic for SAR doesn't make any sense > on a root container region - it does not provide you with a > numerical pixel coordinate system that you can reference. > > Glenn: "contain" came from CSS images and background > positioning rectangle. > > Nigel: That works in the context of images with an internal SAR > in pixels but it doesn't make sense here. > > Glenn: I had proposed using "contain" as a value for > tt:tt/tts:extent to try to match IMSC1's > ... ittp:aspectRatio. > > Nigel: I've understood ttp:displayAspectRatio to be the > equivalent to ittp:aspectRatio. > > Pierre: Yes that is right. I think application specifications > should be left to indicate how to use ttp:displayAspectRatio to > map the root container to the related media object or any > display. > > Glenn: In TTML2 if you have a DAR but the external context's > DAR is different what would you do? > > Pierre: I don't recommend specifying that in TTML2 - it's for > application specifications. > > Glenn: I was trying to map all IMSC1 features - I thought that > was required for TTML2. > > Nigel: Maybe we just need to make IMSC2 contain all IMSC1 > semantics whilst still being a profile of TTML2, so some > details can be left to the IMSC2 profile? > > Glenn: If it's not part of TTML2 then IMSC2 would not be a true > profile. > > Nigel: In that case maybe we need a specified behaviour defined > as a feature in TTML2 so that it can be referenced from IMSC2 > without necessarily requiring that all profiles have the same > behaviour. > ... I propose a feature designator that defines that the > relationship between ttp:displayAspectRatio and the processing > context provided DAR is a "contains" relationship a la IMSC 1 > ittp:aspectRatio. > ... If we have to make IMSC2 a strict profile then it can > mandate support of that feature. > > Glenn: I think I have enough data to try to resolve things > online now, and can modify this according to what we've > discussed. > ... I'll try to make an iteration and see if we can make an > iteration on this. > > Group working model > > Andreas: I'd like to focus telcos on specific topics, one or > two, and know in advance which ones so that we can prepare for > them. > ... I'd also like to ask for confirmation of what we will do on > TTML1 with line gap - Dae asked > ... if we can close it, which is fine by me. I want to check we > don't do what the last comment on the issue says. > > Dae: Yes its issue #209: I propose not to address the issue and > leave it as is. > ... It would be really helpful to push the weekly telcos back > by as long as possible. > > Pierre: I'll have to check. > > Nigel: That would be one hour later, 11 o'clock Boston time. > > Andreas: It's fine for me. > > Nigel: I prefer the current time but could move it back by an > hour. > > Glenn: It wouldn't cause me any trouble. > > Pierre: If we make it one hour later then I won't be able to do > two hours. > > Nigel: I would have that problem too. > > Andreas: If we need that then we should start earlier > exceptionally. > > Nigel: Okay I'll look at that. > > group: Discusses final comment (currently) on #209, agrees not > to change the current agreement to add an informative note by > errata. > > TTML2 issues > > -> [30]https://github.com/w3c/ttml2/issues/53 Inline space. #53 > > [30] https://github.com/w3c/ttml2/issues/53 > > Nigel: We said we needed to come back to this. > > Glenn: We need to separate ipd and bpd from inline block > semantics. > > Nigel: I'd support that. > ... I updated the issue. > > -> [31]https://github.com/w3c/ttml2/issues/119 Add support for > marquee style semantics #119 > > [31] https://github.com/w3c/ttml2/issues/119 > > Nigel: I propose to defer this. > > Glenn: I support moving margin support into TTML>2. > > group: agrees > > Nigel: Done on the issue. > > -> [32]https://github.com/w3c/ttml2/issues/146 Inline block > semantics impacts text wrapping #146 > > [32] https://github.com/w3c/ttml2/issues/146 > > group: discussion of ipd and inline block, and what ipd might > mean. It could be that margin is a better fit for the > requirement than ipd. > > Meeting Closure > > Nigel: Thank you everyone for a productive two days. I'll send > the minutes out and for next > ... week will try to pick one or two specific issues to > discuss, if nobody chooses one for me. > ... [Adjourns meeting] > > Summary of Action Items > > [NEW] ACTION: nigel Mark the TTML2 issues as Discussed and > Agreed where we've discussed and agreed their equivalent TTML1 > issues. [recorded in > [33]http://www.w3.org/2017/01/13-tt-minutes.html#action02] > [NEW] ACTION: pal Update timeline picture to reflect new TTML2 > publication timeline [recorded in > [34]http://www.w3.org/2017/01/13-tt-minutes.html#action01] > > [33] http://www.w3.org/2017/01/13-tt-minutes.html#action02 > [34] http://www.w3.org/2017/01/13-tt-minutes.html#action01 > > Summary of Resolutions > > 1. [35]We will impose a cut-off for new TTML2 features of > Wednesday 15 Feb 2017. > > [End of minutes] > __________________________________________________________ > > > Minutes formatted by David Booth's [36]scribe.perl version > 1.148 ([37]CVS log) > $Date: 2017/01/13 17:12:20 $ > > [36] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [37] http://dev.w3.org/cvsweb/2002/scribe/ > >
Received on Monday, 16 January 2017 07:45:17 UTC