You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
and tts:fontFamily is (inherited from the div) "Arial, Roboto, proportionalSansSerif, default"
which computes to a line height of 100% * 1.2 * 1.5 / 24 = 7.5%
3 lines are visible, which should therefore take up 22.5% of the height.
The region height is 23.478%.
However what we see is that the region height is less than the height of the three stacked lines, rather than more.
What's going on in the browser?
Render area total height = 450px.
Height of one line is expected to be 7.5% of 450px = 33.75px line-height property on the p is indeed set to 33.75px. font-size of the text should be and is set to 28.125px - but on the p's child span, not on the p itself.
Outer span (child of p) computed height is 32px (for all the span children of p).
Inner span (child of outer span) computed height varies:
children of 1st outer span (1st line) have height 37px. (padding-top: 1px; padding-bottom: 4px;)
children of 2nd outer span (2nd line) have height 40px. (padding-top: 4px; padding-bottom: 4px;)
children of 3rd outer span (3rd line) have height 42px. (padding-top: 4px; padding-bottom: 6px;)
This all triggered me to do some experimenting, from which I learned that even though the line-height is being set on the p with an explicit length in px units, the browser overrides it. And it seems to depend on the used values of the font-family and font-size on the p element.
TTML specifies that tts:fontFamily and tts:fontSize only apply to span elements and therefore not to p, with some text that explains that font details do matter when computing line height, but only when tts:lineHeight="normal" which is not the case here. So it seems completely reasonable for imscJS to set those attributes only on spans. However, if I do set them on the p then the result is the line height specified in the TTML.
Proposal
Arguably, for the purposes of reflecting real world implementations, tts:fontSize and tts:fontFamily should apply to p elements in TTML for the purpose of allowing implementations to take them into account when computing the line height. That would be a spec issue on TTML.
In the meantime, I would argue that:
imscJS should set the font-size and font-family properties on the p elements if they're there in the TTML, and
allow CSS inheritance rules to apply, as they do in TTML.
This would allow authorial control as if that spec change had been made, and does not appear to conflict with the spec as it is now. But it would also generate output behaviour that more closely matches the expectation when authoring TTML.
I'd be very interested in counter-arguments to this! Perhaps this approach was adopted before but resulted in other problems I have not noticed.
The text was updated successfully, but these errors were encountered:
Platform: Mac OS X
Browser: Firefox 84.0.1
Input
Sample IMSC document:
Render via http://sandflow.com/imsc1_1/index.html :
Problem:
In this document, we have a
p
with:tts:lineHeight="120%"
tts:fontSize="150%"
ttp:cellResolution="40 24"
tts:fontFamily
is (inherited from thediv
)"Arial, Roboto, proportionalSansSerif, default"
which computes to a line height of 100% * 1.2 * 1.5 / 24 = 7.5%
3 lines are visible, which should therefore take up 22.5% of the height.
The
region
height is 23.478%.However what we see is that the region height is less than the height of the three stacked lines, rather than more.
What's going on in the browser?
Render area total height = 450px.
Height of one line is expected to be 7.5% of 450px = 33.75px
line-height
property on thep
is indeed set to 33.75px.font-size
of the text should be and is set to 28.125px - but on thep
's childspan
, not on thep
itself.Outer
span
(child ofp
) computed height is 32px (for all thespan
children ofp
).Inner
span
(child of outerspan
) computed height varies:padding-top: 1px; padding-bottom: 4px;
)padding-top: 4px; padding-bottom: 4px;
)padding-top: 4px; padding-bottom: 6px;
)This all triggered me to do some experimenting, from which I learned that even though the
line-height
is being set on thep
with an explicit length inpx
units, the browser overrides it. And it seems to depend on the used values of thefont-family
andfont-size
on thep
element.To make this more concrete, I prepared a CodePen at https://codepen.io/nigelmegitt/pen/qBaJZOv showing the effect.
TTML specifies that
tts:fontFamily
andtts:fontSize
only apply tospan
elements and therefore not top
, with some text that explains that font details do matter when computing line height, but only whentts:lineHeight="normal"
which is not the case here. So it seems completely reasonable for imscJS to set those attributes only onspan
s. However, if I do set them on thep
then the result is the line height specified in the TTML.Proposal
Arguably, for the purposes of reflecting real world implementations,
tts:fontSize
andtts:fontFamily
should apply top
elements in TTML for the purpose of allowing implementations to take them into account when computing the line height. That would be a spec issue on TTML.In the meantime, I would argue that:
font-size
andfont-family
properties on thep
elements if they're there in the TTML, andThis would allow authorial control as if that spec change had been made, and does not appear to conflict with the spec as it is now. But it would also generate output behaviour that more closely matches the expectation when authoring TTML.
I'd be very interested in counter-arguments to this! Perhaps this approach was adopted before but resulted in other problems I have not noticed.
The text was updated successfully, but these errors were encountered: