Permit implementations to use fontSize and fontFamily when computing line height

[nigelmegitt]

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. The line-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 and tts:fontFamily clearly do not apply to p elements, so even if the author specifies the font size and family on the p element, implementations are permitted (required, arguably) to ignore them there (for rendering purposes) and use them only as the basis for inheritance down to the span 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 and tts:fontFamily to p 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 and tts:fontFamily stating that their computed values MAY be used when computing line height on p elements, and to reference that from the section that defines tts:lineHeight when the specified value is not "normal".

[skynavga]

@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.27 tts: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.

[palemieux]

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!

https://codepen.io/palemieux/pen/XWjyoLa

[nigelmegitt]

these semantics certainly do (semantically) apply to p in the context of processing tts: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!

[skynavga]

@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 where tts:lineHeight="normal" only.

[nigelmegitt]

@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".

[skynavga]

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

• the TTML2 semantics, [TTML2] §11.3.2.2, §10.2.27, §N.2.1.26, for 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.

• the TTML2 semantics, [TTML2] §11.3.1.4, derived normatively from the following, §11.3.1:

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 the tts:lineHeight attribute as specified in 10.2.27 tts:lineHeight.

Modified 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 the tts:lineHeight attribute as specified in 10.2.27 tts:lineHeight.

i.e., just remove the word normal.

[palemieux]

It sounds like tts:fontSize applies to p.

[skynavga]

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.

[nigelmegitt]

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

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

1. add p back to the applies to boxes, and
2. change the current text in the way that you propose, and
3. (optionally) modify that text to be a Note since the normative part will be in the applies to box.

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:

• tts:fontFamily
• tts:fontSelectionStrategy
• tts:fontSize
• tts:fontStyle
• tts:fontVariant
• tts:fontWeight

[skynavga]

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.

[nigelmegitt]

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.

[css-meeting-bot]

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 full IRC log of that discussion

<nigel> Topic: Permit implementations to use fontSize and fontFamily when computing line height #1215
<nigel> github: https://github.com//issues/1215
<nigel> Glenn: I'm able to open a PR maybe by tomorrow as per Nigel's most recent proposal. I'm fine with that approach.
<nigel> Nigel: Okay, great, thank you.
<nigel> Glenn: I wanted to add one comment, that I didn't necessarily make it clear.
<nigel> .. Based on my analysis, my conclusion was that an implementation that does _not_ take font*** into account now is non-compliant.
<nigel> .. Your original description was that some implementations might not follow that semantic, and my conclusion was that
<nigel> .. not doing so would make it non-compliant according to the letter of the current spec.
<nigel> .. I would agree that it is not easy to pull out that thread of logic from the spec because it requires a fairly good
<nigel> .. understanding of XSL-FO, which since we're talking about CSS might make one wonder.
<nigel> .. The semantic model is fairly clear.
<nigel> .. The way we did the derivation of attributes might make it seem like it's not semantically tied to the XSL-FO definitions.
<nigel> Nigel: Thanks for that.
<nigel> SUMMARY: @skynavga to prepare a pull request on TTML2

[css-meeting-bot]

The Timed Text Working Group just discussed TTML2 Open PRs.

The full IRC log of that discussion

<nigel_> Topic: TTML2 Open PRs
<nigel_> github: https://github.com//issues/1215
<nigel_> Nigel: As far as I can tell we have consensus on this.
<nigel_> .. The pull request is 1216. https://github.com//pull/1216
<atai> q+
<nigel_> ack atai
<nigel_> Andreas: I looked at the discussion and the imscJS change. Looks good to me.
<nigel_> .. Clarifies what is implied, how lineHeight is computed.
<nigel_> .. When looking through I wondered, and we could discuss perhaps.
<nigel_> .. Why in 10.2.27 tts:lineHeight, there is a very detailed algorithm for "normal" and how the different properties work together,
<nigel_> .. but we don't have it for other values.
<nigel_> .. I think that was part of the confusion before. Now it is clear that fontSize applies to p, that's fine.
<nigel_> .. But in the lineHeight section it is not that clear how fontSize is used when the value is not "normal".
<nigel_> Glenn: Are you commenting on this PR or raising this issue to discuss again? I thought we had consensus on how to handle it.
<nigel_> Andreas: It's a question, not an opposition to the PR.
<nigel_> Glenn: Okay then you support the PR?
<nigel_> Andreas: I would like to discuss the question first.
<nigel_> .. It's of course related. If we fix this problem, I would like the explanation why we don't have some explanation in this section.
<nigel_> Glenn: Okay. I agree we don't say anything about the non-normal case specifically.
<nigel_> .. It isn't covered by the multi-point algorithm.
<nigel_> .. The only thing that could mean is that the semantics of line height (see the note about line stacking too) is the derivation section,
<nigel_> .. refers to XSL-FO which refers to CSS. So the only thing one can do is interpret it from that information.
<nigel_> .. There's also a statement about the intent underneath the derivation.
<nigel_> .. It discusses the idea of being compatible with XSL-FO 1.1 and CSS 2.
<nigel_> .. I interpret that intention to be that it comes from the derivation, and that's for both normal and non-normal.
<nigel_> q+
<nigel_> .. That generally applies to many of our other properties like fontFamily, fontSize, fontWeight.
<nigel_> .. We don't go into a whole discussion of the semantics. We effectively delegate to XSL-FO as a default.
<cyril> rrsagent, pointer
<RRSAgent> See https://www.w3.org/2021/02/04-tt-irc#T16-17-47
<atai> q+
<nigel_> Nigel: The question that would excite me, additional to this issue and PR, is has CSS moved on from the CSS2 semantic, and what are the deltas,
<nigel_> .. and what should we do about them?
<nigel_> ack ni
<nigel_> ack pi
<nigel_> Pierre: Changing imscJS to make these attributes applicable to p, and regenerating all the text vectors, it results in sometimes
<nigel_> .. significant change, in a way that isn't always easily predictable. So the algorithm is likely not trivial.
<nigel_> ack at
<nigel_> q+ glenn
<nigel_> Andreas: The issue is really complex. It's not easy to go through XSL-FO etc and it isn't intuitive.
<nigel_> .. The PR solves this concrete implementation problem where fontSize was not applied to p and there was an undesired rendering behaviour.
<nigel_> .. The Pull Request is fine.
<nigel_> .. But in general for the general reader it is not really clear how fontSize on p is really used.
<nigel_> .. I agree with Nigel that it is a bigger problem, and again, like in writingMode, the combination of TTML, XSL-FO, CSS2 (not 2.1!) and what
<nigel_> .. CSS does now and what is used for rendering. As it seems, I think I have heard or read that on purpose it is possibly a bit weak.
<nigel_> .. It is maybe not deterministic what is going on there. For a spec it is not satisfying, but I don't have an answer.
<nigel_> ack gl
<nigel_> Glenn: To comment on it not being intuitive, I would agree wholeheartedly and I would go farther and say it is highly impractical to do
<nigel_> .. anything about it. It is such a complex piece of semantics that it is never going to be intuitive. Even if you only look at CSS this is true.
<nigel_> .. So you're asking for something we can't deliver if you want an intuitive explanation.
<nigel_> .. However historically we had information about derivation about each style property, that refers to a particular section of XSL-FO or CSS.
<nigel_> .. Nigel did a lot of work to move it into the appendix and elaborate it.
<nigel_> .. We have a normative table entry from the style to the derivation appendix information, which happens to be non-normative,
<nigel_> .. because we did not want to demand it, but in effect we do demand it. That's an area where we could entertain making the derivation
<nigel_> .. section normative in the future, because in practice we treat it as normative.
<nigel_> .. The other thing, regarding Nigel's comment about changing from CSS2 to CSS3, that is also impractical. We're so embedded to
<nigel_> .. XSL-FO semantically, which is tied to CSS2, so I think what we would have to do practically is consider on a case by case basis some specific
<nigel_> .. upgrades to semantics. But if we did that we would have to find a way to accommodate any breaking changes that would reflect in our
<nigel_> .. tests. Then we would need a migration path that does not invalidate existing content. You can't simply change that and invalidate the old
<nigel_> .. behaviour (or deprecate). It would need to be a new major version, maybe even a different namespace URI to distinguish the semantic change.