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