London Face to face meeting minutes from Nigel Megitt on 2017-01-13 (public-tt@w3.org from January 2017)

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Fri, 13 Jan 2017 17:52:31 +0000
To: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D49EC458.348AB%nigel.megitt@bbc.co.uk>

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