- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 24 Mar 2016 15:22:32 +0000
- To: W3C Public TTWG <public-tt@w3.org>
- Message-ID: <D3195117.38228%nigel.megitt@bbc.co.uk>
Thanks all for attending today's stimulating TTWG meeting. Minutes in HTML format can be found at https://www.w3.org/2016/03/24-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
24 Mar 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/03/24-tt-irc
Attendees
Present
Andreas, Harold, Nigel, Glenn, Pierre, Thierry
Regrets
Chair
nigel
Scribe
Nigel
Contents
* [3]Topics
1. [4]This Meeting
2. [5]Action Items
3. [6]Charter
4. [7]IMSC
5. [8]TTML
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<scribe> scribe: Nigel
This Meeting
nigel: Andreas and others have requested we spend time looking
at the line area background issue.
... AOB?
group: No AOB
Action Items
<atai> No updates from me
glenn: Regarding a TTML2 WD, the problem is we use an XSL
Transform to convert XML to HTML, and the HTML
... Table of Contents structure is not compatible with the new
ToC sidebar pane. It produces a terrible looking
... result (worse actually). I've started to rewrite that and
got bogged down. It's going to require 2-3 days for me
... to make it work, which I'm hoping to get to by the end of
the month.
Charter
nigel: Thierry, any idea what the status is with the Charter
review?
tmichel: No, I did ping plh but have no update right now -
neither good nor bad news.
nigel: Were Charters on the agenda for the AC meeting?
tmichel: No, they weren't discussed at the AC meeting.
IMSC
pal: I spoke to Coralie at the AC meeting, and she and Karen
are looking for information, quotes, use cases etc
... so I have that on my todo list and if anyone else wants to
help then please do.
... Later on I think we'll discuss the background issue for
line areas, which I think may impact IMSC later.
TTML
nigel: We have two open issues, one on TTML1, the other on
TTML2:
[11]https://github.com/w3c/ttml1/issues/209
[11] https://github.com/w3c/ttml1/issues/209
[12]https://github.com/w3c/ttml2/issues/150
[12] https://github.com/w3c/ttml2/issues/150
nigel: There's been some activity on these issues, especially
some digging about XSL-FO from Andreas and further
... thinking from Glenn - thank you both very much for this.
atai: Before we go into the topic itself it may be good to put
it into context, why the discussion started.
... It's possible that the current behaviour as specified is
not seen as sufficient to comply with presentation
requirements.
... Because they notice this they may go in a different
direction from the spec. Other specs that use TTML may
... add some requirements to what is in TTML to meet
accessibility requirements. This is moving quite fast.
... The key question is how TTWG leads the way in solving this
issue. I think this should be done in an
... interoperable fashion so that everyone uses the same kind
of solution. It's important also to see the timescale
... of how fast we should indicate what we want to do because
this could help others use a solution in line with
... what this group thinks is best.
nigel: I hope that everyone has had a chance to follow the
discussion on the issue. Am I right in thinking that
... we've ended up with a specification trace that the padding
rectangle for spans is the same as the content rectangle
... for TTML1, and is the area in which the background is
painted, and that its height is actually defined?
glenn: That's correct except that the block progression
dimension of the content rectangle is not actually well
... defined. I've been looking at the textGap metric and it
seems to be defined differently in different OSes.
... I determined that the code in blink and webkit uses this
textGap/lineGap metric. At least 4 different browsers,
... Chrome, Safari, Firefox and IE basically matched each other
in the height of the content area that they are
... using. They've possibly reverse engineered each other and
copied the behaviour without a CSS specification
... that really nails that down. So some of the browser
behaviour is not well specified.
... I've discussed this issue with Bert Bos (on various
occasions), and he and I agree that none of the CSS
... specifications defines this well, and is an issue.
... There's another issue whether to look at this as content
rectangle or content rectangle. I'm opposed to
... implementations that arbitrarily modify the padding
rectangle because it could cause a TTML1 vs TTML2
... conflict. I don't think we can use something that uses
padding to expanding the background out, but I do
... think we can do something to address the content rectangle
height. I have a question to answer from Andreas.
atai: Thanks for exploring this and explaining it. One
interpretation is how we should interpret it from TTML1,
... where CSS is not the reference styling language. I think
TTML2 is more looking at CSS which makes sense.
... Although XSL-FO is not the easiest to read I think it is
very well defined and detailed. At least if we want to
... fix the normative behaviour of TTML1 we should be looking
at XSL-FO.
glenn: The problem with that is that XSL-FO refers to CSS. What
it says in one place say regarding line areas
... does not necessarily match CSS implementations. In
particular we chose the line-area line stacking strategy
... because XSL-FO claimed that it was compatible with CSS, but
in fact it might turn out that it is not precisely
... compatible, for example on this issue of computing the
nominal requested line rectangle based on text
... altitude and depth without taking into account the gap
metric.
... I haven't looked at the code in FOP, which I can, but my
guess is it is trying to be compatible with CSS
... and using lineGap.
nigel: I have a colleague who used FOP and the output showed
the background very tight to the text so I suspect
... it does not use line gap.
atai: I'm happy to check with existing FO implementations.
Either way that we look, the content area that is reserved
... just for the text is not the one that fully covers the
height of the line that is also covered by lineHeight.
... For example if you set lineHeight at 400% of the font size
then the content area will not fill the full height of
... the text in the line, independently of whether we're
looking at CSS or FO. In general there's a more strategic
... question of how to deal with it, to open up to
implementation how background colour is painted in inline areas
... in the block progression dimension, or do we see an
immediate need to add some extra vocabulary to control
... that behaviour, and if we want extra vocab, in which spec
it should be and how fast we can have that solution.
... The first question is most important - do we want to
restrict all implementations to follow a single interpretation
... of TTML1 or do we want to allow room for further
specification?
pal: As a minimum, if there's a single way of stacking lines
etc then that should be written down somewhere.
... Secondly, if we need to control that strategy to allow for
authorial control then we'll figure out a parameter or
... way to do that. There may be a way to do that, but the
first step I think is to explain the current strategy.
nigel: [explains thinking behind padding extension possibility,
and that it should be possible to do this without blocking
TTML2]
glenn: In TTML1 padding is clearly defined as 0, so there is no
ambiguity there now. Saying that padding could
... be extended is I think the wrong approach because it does
not address the ambiguity in content rectangle height.
... My contention is that we can define the content rectangle
height clearly and retain padding semantics independently.
... The problem of using padding is that it mixes the semantics
of content rectangle height and padding rectangle
... in a way that is problematic in my view.
... I think we should start with content rectangle height, and
I have a proposal to do that. The way forward is to
... drill down on that and see if it works or not.
nigel: That's fine - we should certainly clarify the content
rectangle if we can. My thinking to use the padding
... rectangle is that it's clearly specified that background
areas are painted in the padding rectangle, so that is
... the concept that most closely matches the problem.
atai: We also need to check if there is any impact on
positioning or other concepts if we adjust the content
... rectangle.
... I think there's another approach which is to specify the
background area, leaving all the other concepts as they
... are. This would also be a solution, for me, because it
would describe the semantic for all implementations,
... even those that do not use CSS or XSL-FO engines. We should
possibly just consider the solution for drawing
... backgrounds.
glenn: I think the first point from Andreas is about the impact
of changing the content rectangle on the baseline
... and that's something that came up in the discussion with
Bert. In the simple case of using a single font for a
... whole line isn't really an issue, but if a mix of fonts or
scripts on the same line is used then it becomes more
... complex. I agree that we shouldn't do anything that mucks
up the standard model for baseline. I think we can
... do it without mucking that up. On the second point about
redefining where and how background color is
... rendered, I don't think we can do it any other way than by
making it the padding rectangle. The first point of
... order is to see if changing the content rectangle
definition will satisfy the problem. If not then we can
consider
... the padding rectangle solution, which I'm very reluctant to
entertain because of the impact on TTML2.
... In response to Andreas's comment at
[13]https://github.com/w3c/ttml1/issues/209#issuecomment-200822
590
... I don't think that the comment is quite accurate, because
the height of the line area rectangle is determined by
... taking the minimum height that encloses the expanded
nominal requested rectangle of each inline area, based
... on the font of the paragraph... If you expand this to
include leading then you don't need to add leading. Maybe
... we can continue that offline.
[13] https://github.com/w3c/ttml1/issues/209#issuecomment-200822590
atai: I think so - that needs some further thought.
... We've made some good progress over the last few weeks, but
we cannot come to a conclusion today. I want
... to go back to the question of the default behaviour and
adding extra vocabulary. The default behaviour now is
... not what is wanted. Still we have the option of using
Glenn's solution and a default of "auto" is still
implementation
... dependent. It is good to rely on a solution that would fit
now and also in the future on TTML2, but I wonder
... if there is a way to get it into an IMSC publication before
TTML2. For a lot of specs IMSC is now the core
... reference, and we all want the sub-profiles that depend on
IMSC. I see a solution based on a timel
glenn: I think we can do better than defining an arbitrary
default. We can define in an errata for TTML1 a note that
... elaborates the semantics of content rectangle heights more
clearly, and that it doesn't need to mention say
... "auto" specifically but could define the default behaviour
in a way that allows for some flexibility. If the
... implementation does not have an opinion on this then we can
suggest that a default default applies, for example
... one of the options that we define in TTML2, say text
altitude + text depth + text gap, or an extension to the
... line area. We could make a TTML1 errata very quickly to
satisfy the immediate need and then pave the way for
... a more elaborate solution in TTML2 and IMSC 2 presumably.
IMSC 1 itself could simply adopt the TTML1 errata
... in order to get to the default behaviour that we're looking
for.
pal: I really like that proposal.
nigel: +1
pal: I think people may want the behaviour to be controllable,
so we should make clear that the behaviour is
... clearly parameterisable so that we can carry that forward
into TTML2.
glenn: Since we cannot add new functionality to TTML1 the best
we can do is suggest that a future version could
... provide more authorial control, and indicate what that may
be.
pal: That's what I had in mind.
nigel: The parameters could also be provided externally to the
document.
glenn: That's what I was going to suggest, that the
implementation could have a parameter that is outside of the
... document, just like is the case for forced display
semantics.
atai: I think that this errata proposal could be a good way out
for immediate requirements because then if some
... spec needs an immediate solution they possibly could add
some extra vocabulary that tries to be inline with
... what may come up, and this would then make it easier for
the transition to TTML2.
glenn: The most important thing is for Andreas and me to
continue our discussion, and if we can get consensus
... then that will give me clear indication on what I can
propose in an errata, so if we can reach that fairly quickly
... then I'll propose an errata straight after that.
nigel: Sounds great to me.
pal: If there is an external group with an interest in this
then it would be awesome to have communication from
... that group to explain what they're wanting to do.
glenn: I agree but I would suggest that we do not request them
to propose a solution.
... We've already got a statement of the problem - as long as
we give them that behaviour then that would be okay.
atai: I would also support what Pierre says, that having the
communications to make sure we are aligned would be really
great.
nigel: Thanks everyone. We're out of time, so just summarising
where I think we're up to:
... There's an action on Andreas and Glenn to conclude on their
current discussion;
... And one on me to see if we can get communications from the
groups that are interested in this behaviour;
... And we have consensus on producing a TTML1 errata note to
explain this.
... Next week I won't be around, and Pierre has kindly
volunteered to chair.
... Thanks everyone! [adjourns meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [14]scribe.perl version
1.144 ([15]CVS log)
$Date: 2016/03/24 15:21:05 $
[14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[15] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 24 March 2016 15:22:59 UTC