Improve descriptive prose and elaborate computed value semantics of t… #336
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9774,26 +9774,57 @@ then relative to nearest ancestor <loc href="#terms-styled-element">styled eleme | |
| </tbody> | ||
| </table> | ||
| <p>If a single <loc href="#style-value-length"><length></loc> value is specified, then this length applies | ||
| equally to the horizontal and vertical size of a glyph's EM square; | ||
| if two <loc href="#style-value-length"><length></loc> values are specified, then the first expresses the horizontal | ||
| size and the second expresses vertical size.</p> | ||
| <p>If horizontal and vertical sizes are expressed independently, then the | ||
| units of the <loc href="#style-value-length"><length></loc> values must be the same.</p> | ||
| <note role="clarification"> | ||
| <p>A glyph's EM square is conventionally defined as the EM square of the font that contains the glyph. That is, | ||
| glyphs do not have an EM square that is distinct from their font's EM square.</p> | ||
| </note> | ||
| <p>Relative <loc href="#style-value-length"><length></loc> values | ||
| that appear in this attribute, i.e., values expressed in percentage (<code>%</code>), cell (<code>c</code>), or EM (<code>em</code>) units, | ||
| are resolved in relation to a referenced 2-dimensional size value consisting of two components, a width component and | ||
|
There was a problem hiding this comment. I do not think this example is correct; specifically in the width component. My expectation here is that a single length value results in a tuple of This is important because the PAR might not be 1. For example, if the PAR is 1.5 and the font size height is 36px then it would be reasonable for the implementation to deduce that the equivalent width of the em square in logical pixels is 24px; note that PAR is not guaranteed to be known at document authoring time. Instead the document author is saying "render some text without anamorphic scaling, so that it is this high." That's an important semantic that we remove by saying that the em square is always scaled to a specific width in logical pixels. There was a problem hiding this comment. I have no idea how you came to that conclusion, as it is justified by nothing in TTML, XSL-FO, or CSS. TTML1 (and earlier) clearly say:
How can you read that and conclude that the horizontal size (width) of the EM square is unresolved. Furthermore, what does PAR have to do with this discussion. We are speaking of logical pixels here only. Discussing PAR (and corresponding display pixels) is entirely orthogonal. The bottom line is that if one length is specified or if two lengths are specified whether the values are the same, then the EM Square is, well, square. However, if two unequal lengths are specified, than an EM Square is really a non-square rectangle. Mapping this square to display pixels (based on pixels having a PAR aspect ratio) is unrelated to font sizes or lengths based on font sizes. As for your example of PAR of 1.5 with font size 36px, then the EM square is 36px by 36px in logical pixels which maps to a 36px by 36px rectangle in display pixels. In both cases, the EM square is 36px by 36px. However, in logical pixels we can't talk about aspect ratio (or if you insist, then you can just declare they are square), but in display pixels, now we can certainly talk about aspect ratio of pixels (=PAR). So a 36px by 36px box (in hypothetical square logical pixels) now becomes a 36px by 36px rectangle with a width to height ratio of 1.5 in display pixels. There was a problem hiding this comment.
It is unresolved at authoring time. Also it is a length here, not a "number of pixels" and they are different things depending on PAR. At best the meaning of "length" differs depending on perspective - a person using non-technical terms would think that you might measure the horizontal length and the vertical length with a ruler on the display and find that they come out the same. In other words, it is not clear that it is meant in a technical sense of "number of pixels". Reading your comment above, it means that when PAR is not 1, even a single value font size, say There was a problem hiding this comment. First, we are only talking about presentation time here. Authoring time is irrelevant. Second, we are talking about logical pixels here and PAR has no relevance. Length in TTML2 never means a physical, measurable distance. An "EM square" (in TTML2 measurement terms, i.e., logical pixels) is indeed non-square when PAR is not 1 (unless another transformation to aspect ratio occurs post-TTML output that inverts PAR (but that is out of scope). There was a problem hiding this comment.
Clearly for every document author authoring time is completely relevant. You can't just sweep it out of scope of the semantics we specify. By the logic put forward here it is actually impossible for a document author to specify "I only want non-anamorphic font display", which is the usual semantic on the web platform; further almost all implementations now would fail to be conformant unless PAR is 1, which cannot be relied upon unfortunately. These two things can't be what we want.
That is why I preferred to refer to the horizontal dimension as "undefined". There was a problem hiding this comment. First, it is a general truth that an author does not know whether the eventual display will be anamorphic or not, and we cannot address this problem. As we now note in H.1 [1]:
However, the author can state they want display pixels that are square. They merely need to specify Regarding
You keep insisting on thinking in display pixels. It is most definitely not undefined in logical pixels and that is what every discussion of length and measure assumes in TTML2. [1] https://w3c.github.io/ttml2/spec/ttml2.html#root-container-region-semantics-aspect-ratios There was a problem hiding this comment.
No, that's orthogonal to the semantic of "just set the height"; furthermore since PAR is given the least priority in H.1.4, it is possible that even if the author intends a particular PAR it will not be the actual one that applies. What is the impact of anamorphically scaling (ideographic) glyphs in top to bottom writing modes? It's not my area of expertise but it seems as though the width is not nearly as important as the height in that case, but an unintended horizontal squeeze or stretch could adversely impact the readability. |
||
| a height component. If the relative unit is a percentage, then the referenced value is either the computed value | ||
| of the font size of the nearest styled ancestor element or the <loc href="#terms-computed-cell-size">computed cell size</loc>. | ||
| If the relative unit is cells (<code>c</code>), then the referenced value is the | ||
| <loc href="#terms-computed-cell-size">computed cell size</loc>. | ||
| If the relative unit is EMs (<code>em</code>), then the referenced value is determined as if percentage units | ||
| were used, where <code>1em</code> equals <code>100%</code>.</p> | ||
| <p>When a single relative <loc href="#style-value-length"><length></loc> value is specified, then | ||
| this <loc href="#style-value-length"><length></loc> is resolved in terms of the height component of the referenced value; | ||
| when two relative | ||
|
There was a problem hiding this comment. This I need time to think about this some more. There was a problem hiding this comment. The definition of
So, any value of There was a problem hiding this comment. OK thanks for the elaboration. |
||
| <loc href="#style-value-length"><length></loc> values are specified, | ||
| the first <loc href="#style-value-length"><length></loc> is resolved in terms of the width component of the referenced value and | ||
| the second <loc href="#style-value-length"><length></loc> is resolved in terms of the height component of the referenced value.</p> | ||
| <note role="example"> | ||
| <p>Anamorphic font scaling, i.e., fonts scaled to independent (and distinct) horizontal and vertical sizes, | ||
| is expected to be used in a number of contexts, such as | ||
| when an author desires to synthesize a narrow or wide font face, | ||
| when an author desires to employ font sizes based on non-square cell units, etc.</p> | ||
| </note> | ||
| <p>The <loc href="#style-value-length"><length></loc> value(s) used to express font size must be non-negative.</p> | ||
| <p>If the value of this attribute specifies a <code>c</code> unit on a <loc href="#style-value-length"><length></loc> component, | ||
| then it is resolved in terms of the height (only) or (both) the width and height of a | ||
| <emph>cell</emph> length unit as defined by <specref ref="style-value-length"/>, which is to say, in terms of | ||
| the <loc href="#terms-computed-cell-size">computed cell size</loc>.</p> | ||
| <note role="example"> | ||
| <p>For example, consider a paragraph (<code>p</code>) element <code>P</code>. | ||
|
There was a problem hiding this comment. This example is inconsistent in presentation with the one on span, at line 9822 - why are "paragraph" elements augmented with a "( |
||
| If the <loc href="#terms-computed-cell-size">computed cell size</loc> is (24px,36px), and if | ||
|
There was a problem hiding this comment. As per the discussion in #200 (comment) the sizes here are in logical pixels - in fact they are dimensionless until multiplied by the size of the pixel unit, whatever that turns out to be. Consider adding a parenthetical (in logical pixels) to avoid confusion with "real" pixels. |
||
| <code>tts:fontSize="1c"</code> is specified on <code>P</code>, then the computed value of <code>tts:fontSize</code> | ||
| resolves to (36px,36px), while if <code>tts:fontSize="1c 1c"</code> is specified on <code>P</code>, | ||
| then the computed value resolves to (24px,36px).</p> | ||
| </note> | ||
| <p>If the value of this attribute specifies an <code>em</code> unit on a <loc href="#style-value-length"><length></loc> component, | ||
| then it is treated as if an equivalent percentage value were specified, where <code>1em</code> is equal to <code>100%</code>.</p> | ||
| <note role="example"> | ||
| <p>For example, consider a span element <code>S</code>, a child of a paragraph (<code>p</code>) element <code>P</code>. | ||
| If the computed value of <code>tts:fontSize</code> on <code>P</code> is (18px,24px), and if | ||
| <code>tts:fontSize="1em"</code> is specified on <code>S</code>, then this is equivalent to specifying <code>100%</code>, | ||
| which resolves to (24px,24px). However, if <code>tts:fontSize="1em 1em"</code> is specified on <code>S</code>, | ||
| then this is equivalent to specifying <code>100% 100%</code> which resolves to (18px,24px).</p> | ||
| </note> | ||
| <p>If a computed value of the property associated with this attribute is not supported, | ||
| then a <loc href="#terms-presentation-processor">presentation processor</loc> must use the closest supported value.</p> | ||
| <note role="elaboration"> | ||
|
|
@@ -9802,15 +9833,6 @@ the computed font size and the supported font size is minimized. If there are mu | |
| the computed value, then the value most distant from 0 (single length specification) or [0,0] (two length specifications) is used, | ||
| i.e., the largest font size, is used.</p> | ||
| </note> | ||
| <p>The <att>tts:fontSize</att> style is illustrated by the following example.</p> | ||
| <table id="style-attribute-fontSize-example-1" role="example"> | ||
| <caption>Example Fragment – Font Size</caption> | ||
|
|
@@ -9856,6 +9878,8 @@ width and height independently is an extension introduced by TTML.</p> | |
| </note> | ||
| <div4 id="style-attribute-fontSize-special-semantics"> | ||
| <head>Special Semantics</head> | ||
| <p>The computed value of the property associated with this attribute consists of a 2-tuple | ||
| the entries of which denote the computed values of the width and height components of the font size respectively.</p> | ||
| <p>When applied to a <loc href="#content-vocabulary-span"><el>span</el></loc> element | ||
| for which the computed value of <loc href="#style-attribute-ruby"><att>tts:ruby</att></loc> is | ||
| either <code>textContainer</code> or <code>text</code>, then, when resolving the computed value | ||
|
|
@@ -12972,9 +12996,9 @@ represented by this attribute are based upon that defined by <bibref ref="xsl11" | |
| <div4 id="style-attribute-textDecoration-special-semantics"> | ||
| <head>Special Semantics</head> | ||
| <p>The computed value of the property associated with this attribute consists of a 3-tuple, | ||
| where each entry denotes, respectively, whether an underline, line through, or overline | ||
| decoration is to be applied to the affected text. | ||
| Furthermore, when applying inheritance semantics, each of these entries is considered to | ||
| be inherited separately from the others.</p> | ||
| <note role="example"> | ||
| <p>For example, if the computed value of <code>tts:textDecoration</code> that applies to a <code>div</code> (division) element | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This loses the sense that the font-defined glyph generally needs scaling to the precise display dimensions of the em square, and specifically always needs scaling anamorphically to achieve a different width to the height. I think this needs to be brought back in somehow, though I like the idea of specifying the resultant size of the em square unambiguously.