See also: IRC log
<scribe> scribe: Nigel
nigel: Andreas and others have
requested we spend time looking at the line area background
issue.
... AOB?
group: No AOB
<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.
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.
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.
nigel: We have two open issues, one on TTML1, the other on TTML2:
https://github.com/w3c/ttml1/issues/209
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
https://github.com/w3c/ttml1/issues/209#issuecomment-200822590
... 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.
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]