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

On Fri, Feb 19, 2016 at 12:07 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> From: Glenn Adams <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>
> wrote:
>
>> From: Glenn Adams <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>
>> 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.
>

I'm still considering the appropriate default.


>
> 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?
>

I agree, it isn't strictly needed. However, automatic algorithms (like
bbox|lineHeight) may not be sufficient in all cases, thus the ability to
manually adjust can be useful for tweaking things. If we are going add one
of these, we might add both.


>
> 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
>>
>>
>