Address ambiguity in 'tts:lineHeight' normal algorithm (#1241).#1242
Address ambiguity in 'tts:lineHeight' normal algorithm (#1241).#1242skynavga wants to merge 1 commit into
Conversation
| defined by <bibref ref="css3-fonts"/>, it is intended that the phrase <emph>the first font obtained</emph>, as used in the previous text, refers to the | ||
| first font whose <loc href="#embedded-content-value-unicode-range"><unicode-range></loc> includes the U+0020 (space) character, |
There was a problem hiding this comment.
I don't recognise this intent as anything that TTWG discussed. However, I think it's obvious that the CSS algorithm needs to be considered a valid implementation.
Rather than duplicating the definition of the CSS algorithm, can we reference it instead, simplifying this text? Something along the lines of "This requirement is intended to be compatible with the CSS3 font algorithm for selecting the first font obtained; however if that algorithm is used, then it effectively overrides any semantic defined by tts:fontSelectionStrategy when determining line height."
There was a problem hiding this comment.
that won't work for a number of reasons, which I would be happy to explain in a ttwg call
There was a problem hiding this comment.
The next TTWG call will be in September, so it would be worth sketching out the reasons here in order to make progress sooner.
There was a problem hiding this comment.
Primarily:
- CSS Font Module Level 3 (which TTML2 references) has slightly different wording that has been updated since in CSS Font Module Level 4; namely, "the first available font that would match the U+0020 (space) character" (CSS Fonts 3) vs "the first font whose unicode-range includes the U+0020 (space) character" (CSS Fonts 4); see also [css-fonts] Reconsider the definition of "first available font" csswg-drafts#4796;
- AFAICT neither CSS Font Module Level 3 nor 4 specifies what it means to evaluate the unicode-range of a system (built-in) font;
- neither CSS Font Module Level 3 nor 4 has our
<font/>element, but instead has a@font-facerule, so we need language that refers to the unicode-range, i.e., our@rangeattribute (either specified or defaulted);
Bottom line is we can't reference CSS Font Module Level 3 for the language we need, and we still need to add language about the meaning of unicode-range, all together ending up with about the same (if not more) text in the note.
There was a problem hiding this comment.
I see that CSS Fonts 4 probably needs some further work here, which means the CSS algorithm with which we should be compatible is effectively unstable right now. That suggests to me that we should not make any change until it is stable, and we should highlight the issues regarding unicode-range on that specification.
There was a problem hiding this comment.
- AFAICT neither CSS Font Module Level 3 nor 4 specifies what it means to evaluate the unicode-range of a system (built-in) font;
I just added a comment at w3c/csswg-drafts#4796 (comment) relating to this.
It seems to me that any font selection needs to happen after processing any <font>s and be based on the tts:fontFamily list. This is actually the same in both CSS and TTML, if we can assume the same intent of processing any font loading directives beforehand.
To do that would require alternative wording though, both here and in CSS, to refer to the existence of the 0x0020 character in the font's "character map" regardless of how that map has been derived.
Does this seem reasonable to you @skynavga ? I'm slightly worried that I've missed something...
There was a problem hiding this comment.
The solution at w3c/csswg-drafts@abbc961 for CSS (that closed w3c/csswg-drafts#4796) looks like it could be applied here too, even if by using similar phrasing rather than by reference, in other words:
- The unicode range of a local font is assumed to include all code points
- The unicode range of a referenced font is defined by the
fontelement'srangeattribute. - The test is then that the unicode range includes U+0020.
Alternatively we could say that for interpreting as per CSS the font element's range attribute must be taken to define the unicode-range descriptor as in CSS.
There was a problem hiding this comment.
For this issue, i.e., for finding the first font having a mapping for 0x0020 (SPACE), it would be best to phrase the first bullet above as "the unicode range of a built-in font resource must include U+0020 for it to be a candidate for the first font obtained" or something to this effect.
3 participants
Closes #1241.