Closed nigelmegitt closed 3 years ago
@nigelmegitt at one point, we had specified that tts:fontFamily
and tts:fontSize
applied to p
; however, we ended up adopting special language that explicitly assigns semantics to the use of these styles by p
, in particular, under both of these properties (and a number of other font related properties) appears the language:
In addition to applying to span, the computed value of this property on a p element is used to resolve the normal value of the style property associated with the
tts:lineHeight
attribute as specified in 10.2.27tts:lineHeight
.
As a consequence, these semantics certainly do (semantically) apply to p
in the context of processing tts:lineHeight
, regardless of whether we list p
in the applies to block of the definitions of these properties. Further, suggesting that these semantics are not required on the part of the implementation would effectively be ignoring normative text.
In HTML/CSS implementations, even if the line-height property on a p element is set to a pixel based length, the line height that results depends on the used vales of font-size and font-family on that p element.
@nigelmegitt Do you know if this is an implementation choice, or is this specified by CSS?
As illustrated in the following codepen, setting font-size
smaller seems to increase the line height in some circumstances!
these semantics certainly do (semantically) apply to
p
in the context of processingtts:lineHeight
@skynavga yes - and I'm proposing that we extend the language to clarify that even when tts:lineHeight
is a value other than "normal"
tts:fontFamily
and tts:fontSize
can be used in the computation of the line spacing that is used. As I read it the current language constrains the semantic application to p
to the case where tts:lineHeight="normal"
only.
Do you know if this is an implementation choice, or is this specified by CSS?
@palemieux from my reading of the current CSS 2 ED (which I guess is most likely to reflect current implementations), line-height
specifies the minimal height only, and it is permitted for implementations to use it as the basis for calculating the actual line spacing, where that results in a different value. This is what I see in practice. I have the impression that the freedom provided in the spec is the (or has so far been) only achievable consensus due to the different behaviours across implementations.
Your codepen does seem to show surprising behaviour!
@nigelmegitt ok, I understand, though I would not say it constrains, but rather does not define semantics for the non-"normal" cases;
As I read it the current language constrains the semantic application to
p
to the case wheretts:lineHeight="normal"
only.
@skynavga It looks to me like there's a direct trace from the TTML2 spec now to imscJS's implementation that sets font-family
and font-size
properties only on HTML span
elements regardless of where the equivalent TTML attributes are specified - as the implementer, @palemieux may tell us otherwise of course. It's on that basis that I'm seeking to add spec text to TTML2 to clarify that there is indeed the freedom that you imply by "does not define semantics".
@nigelmegitt I have carefully reviewed the TTML2 text, and now withdraw my above statement regarding "does not define semantics". The question you ask is whether there is specification support for the use of tts:fontSize
as specified on p
for the purpose of resolving tts:lineHeight
when its specified (or default) value is 'normal
. I believe I can answer in the affirmative, which I derive as follows:
tts:lineHeight
when its value is not normal
is based on [XSL-FO] §4.5 per-inline-height-rectangle, which in turn is (in part) based on the nominal-requested-line-rectangle, which is computed as:whose before-edge is separated from the baseline-start-point by the text-altitude of the parent block-area, and whose after-edge is separated from the baseline-start-point by the text-depth of the parent block-area
where it should be noted that computing the text-altitude and text-depth of the parent block-area requires evaluating a combination of font related style properties that must be considered to (logically) apply to a p
element, lest one could not compute the text-altitude and text-depth of the parent block-area; these include, at a minimum, tts:fontSize
, tts:fontFamily
, etc.
Any implementation is permitted provided that the externally observable results are consistent with the results produced by this model.
This text explicitly sanctions implementations, such as imscJS, which maps TTML2 to CSS/HTML, to apply tts:fontSize
, etc. to HTML p
and its CSS styles.
If we were to make an improvement to [TTML2], then my suggestion would be to change the normative language found under tts:fontSize
et al as follows:
Current Text
In addition to applying to span, the computed value of this property on a p element is used to resolve the
normal
value of the style property associated with thetts:lineHeight
attribute as specified in 10.2.27tts:lineHeight
.
Modified Text
In addition to applying to span, the computed value of this property on a p element is used to resolve the
value of the style property associated with thenormal
tts:lineHeight
attribute as specified in 10.2.27tts:lineHeight
.
i.e., just remove the word normal
.
It sounds like tts:fontSize
applies to p
.
Yes, that's another way of saying it. The alternative change is to remove all of those paragraphs (see Current Text above) and add p
back to the applies to boxes for those styles we remove Current Text.
I'm not sure if I have a preference either way.
The question you ask is whether there is specification support for the use of
tts:fontSize
as specified onp
for the purpose of resolvingtts:lineHeight
when its specified (or default) value is 'normal`.
@skynavga I think you missed out a "not" there! Sorry to repeat, but in case of confusion in others reading this, I'm asking about the situation when the specified value is not normal
. The rest of your response is about the situation I am asking about.
I like both suggestions, and my preference is to do all of:
p
back to the applies to boxes, and I'm willing to be persuaded otherwise; the reason for my preference is that I think it is clearer, and it effectively mandates processors to compute the relevant style attribute values and set them on [their equivalent of] p
elements. The alternative is that this is left implementation-dependent and two different conformant implementations, that might both, say, be using CSS for styling, result in significantly different presentations, if one does compute and set the equivalent properties on the p
element and the other doesn't.
For reference, the places where I can find the affected text in TTML2 2nd Ed CR:
I think you missed out a "not" there!
Thanks for correcting. I meant "not normal
".
my preference is to do all
That works for me.
it effectively mandates processors to compute the relevant style attribute values and set them on [their equivalent of] p elements
I believe my analysis shows that however an implementation accomplishes it, it is required to exhibit the said behavior already according to existing text, which makes the proposed change effectively semantically non-substantive, even though it alters normative text.
makes the proposed change effectively semantically non-substantive, even though it alters normative text.
That's a useful thing to notice, since it wouldn't change the implementation report.
The Timed Text Working Group just discussed Permit implementations to use fontSize and fontFamily when computing line height w3c/ttml2#1215
, and agreed to the following:
SUMMARY: @skynavga to prepare a pull request on TTML2
The Timed Text Working Group just discussed TTML2 Open PRs
.
In HTML/CSS implementations, even if the
line-height
property on ap
element is set to a pixel based length, the line height that results depends on the used vales offont-size
andfont-family
on thatp
element. Theline-height
is taken as a minimum (as per the CSS spec) and the font metrics are taken into account to increase the size if the implementation sees fit.See https://codepen.io/nigelmegitt/pen/qBaJZOv for an example of this.
However in TTML, the equivalent style attributes,
tts:fontSize
andtts:fontFamily
clearly do not apply top
elements, so even if the author specifies the font size and family on thep
element, implementations are permitted (required, arguably) to ignore them there (for rendering purposes) and use them only as the basis for inheritance down to thespan
level, where it does apply.This can be surprising for content authors, who find that depending on context, the line height may not match what they specify in the TTML.
The specification for computing actual line height allows some freedom, so this is not "broken" per se. However we would allow authors a greater degree of control, and more closely match existing CSS-based implementations, if we were to allow presentation processors to apply
tts:fontSize
andtts:fontFamily
top
elements in TTML solely for the purpose of computing line height.For example see also sandflow/imscJS#201 which proposes passing these attributes into the style attribute of the HTML
p
element when rendering an ISD, to achieve the expected line spacing.Concretely, this issue proposes to add a special semantic to
tts:fontSize
andtts:fontFamily
stating that their computed values MAY be used when computing line height onp
elements, and to reference that from the section that definestts:lineHeight
when the specified value is not"normal"
.