Re: ISSUE-302 (line spacing vs line height): Should background of a span be height of text in line or computed lineHeight? [TTML2]

Thanks Glenn,

Though we could add an informative note to the errata for TTML1SE I do not think there is a pressing need to do this.

I raised Issue-302 on the TTML2 product, so I'd be happy as a resolution for this issue to ensure that the text describing padding on spans and on backgroundColor and lineHeight makes clear the difference between the concepts and the resulting behaviour. One way to achieve this would be to add an example. I don't have a specific proposal for this right now but when the work on related issues is concluded am happy to revisit this to crete a proposal – of course others are welcome to make proposals here too.

Kind regards,

Nigel


On 20/03/2014 17:12, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:

With attachment.


On Thu, Mar 20, 2014 at 11:11 AM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


On Thu, Mar 20, 2014 at 5:34 AM, Timed Text Working Group Issue Tracker <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>> wrote:
ISSUE-302 (line spacing vs line height): Should background of a span be height of text in line or computed lineHeight? [TTML2]

http://www.w3.org/AudioVideo/TT/tracker/issues/302


Raised by: Nigel Megitt
On product: TTML2

TTML1SE says that lineHeight "is used to specify a style property that defines the inter-baseline separation between line areas" However it is unclear what the height of the line areas is, for the purpose of drawing the background as specified on a span. Is it identical to the computed line height, or is it related to the height of the line areas created based on the text contained within the span, independent of the baseline separation of those line areas?

The XSL-FO line area definition [1] appears to be relevant, though I'm not sure if it resolves the question.

[1] http://www.w3.org/TR/2006/REC-xsl11-20061205/#area-line


Since TTML1 adopts the semantics of XSL-FO for block and line layout, and since XSL-FO refers to CSS for the semantics of inline style properties such as background-color, then the CSS property semantics apply.

In this case, background color applied to a span extends to the height of the inline box generated by the span, and if that box's computed height is less than the computed line height assigned to the line area, then there will be gaps between the before/after edges of the inline box and the containing line box.

See the attached test file as an example.

If we had supported padding on content elements in TTML1, then one could manually add padding-before/after (top/bottom) to the spans to extend the height of the inline's background, but unfortunately we didn't add this until TTML2.



We need to address this additionally for any mapping to HTML/CSS because it appears that a simple mapping of TTML concepts into CSS could introduce 'no background paint' areas in between lines.

If the two concepts may be computed to have different values this introduces the possibility that between two lines separated by e.g. a <br/> an empty 'no background paint' area may be introduced. I would argue that this is highly undesirable aesthetically when lineHeight is approximately the same as the line area height, e.g. in the range 80-125%. However if the two concepts must always have identical values this possibility would not arise; instead lines may be spaced far apart (for a large lineHeight) and the entire height would be painted with background colour. This latter option may also be undesirable in some use cases.

This issue is related to Issue-284.









----------------------------

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.

---------------------