Re: {minutes} TTWG Meeting 2016-02-18

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Friday, 19 February 2016 18:23

On Fri, Feb 19, 2016 at 10:55 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Thursday, 18 February 2016 18:50


On Thu, Feb 18, 2016 at 9:05 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:

[snip]



TTML2

   nigel: Just to note that we have a merged PR, which I
   submitted, which updates all the issue links to point to
   github.
   ... The media timing semantics PR is still open.
   ... There's also been discussion of the use of inline block
   semantics.

   [15]https://github.com/w3c/ttml2/issues/146


     [15] https://github.com/w3c/ttml2/issues/146


   nigel: On this one I was concerned that the semantics lead to
   unwanted behaviours, but I think we can get around them
   ... mostly using nested span. The only outstanding issue I
   cannot find a way to solve right now is that BBC wants to be
   ... able to paint background areas behind spans that have the
   same height as lineHeight, and we cannot see a reliable
   ... way to do this. I plan to file an issue within the next
   week unless we can work out how.
   ... I can't see a way yet to achieve this in CSS, and it may
   need a new semantic on tts:padding to allow that to happen.

It would be useful to see some images depicting desired results; this looks similar to a problem I addressed in an SVG implementation (batik) to add support for background coloring of text and tspan elements, wherein I defined:

Something like the attached might help. The line height is in general larger than the font size, and we wish to extend the background area of each line area to match the line height so that adjacent line areas are drawn without any gap in background.

An effect similar to this is achieved on most browsers by using inline display semantics but I have been unable to make this work alongside other constraints such as text wrapping and white space pruning.

I haven't found a way to do it in CSS, but it can be done reliably in Javascript by querying the line areas heights and then updating padding. Clearly we want a solution that is not dependent on scripting if possible, though mapping a new non-CSS semantic may require it of course.


background-color: <color>
background-mode: bbox | lineHeight
background-padding: <length>{1,4}

The second of these, background-mode, determined the extent of the rectangles to colorize;

That seems exactly what we want.

the third of these, background-padding, allows manually extending the background color rectangle on any of the edges.

We could do something like this in TTML2; however, it might not readily translate to an HTML/CSS based renderer.

I'd like to explore how we can express this semantic in TTML2. Any suggestions?

I would suggest we add the following style property attributes (names to be considered tentative at this point):

tts:backgroundColorBounds: bbox | lineHeight (default:

Did you omit the default? I guess for backward compatibility it would be bbox and anyone wanting the alternate behaviour would be able to specify a different "initial" value.

tts:backgroundColorOutdent: <length>{1,4} (default: 0px)

I'm not sure we strictly need this – perhaps there's a reason for having it that I haven't understood?

We may need an additional value on the first that effectively means lineHeight + leading, depending on whether the definition of line height includes leading or not. [I think you want line height + leading (if line height does not already include leading),  or just line height (if line height includes leading).]

Yes that's what I think I want too.

I use 'Outdent' suffix in the latter, as opposite of 'Indent'; 'Outset' is another option (opposite of 'Inset'); 'Padding' and 'Outline' are also options but may be confused with existing usage. Suggestions are welcome.

From a CSS perspective we're increasing the padding area, if I've understood correctly, so 'padding' isn't a bad option. Also, I mentioned that a fix for this can be achieved in CSS with Javascript – that fix modifies the padding. So I think padding is most closely aligned to the semantic. Other views most welcome.

Nigel




[snip]

Nigel