London Face to face meeting minutes

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 Friday, 13 January 2017 17:53:07 UTC