Two value percentage fontSize not fully defined

[nigelmegitt]

If a two value percentage based tts:fontSize is used and an ancestor element specifies a single value absolute size, the horizontal component is undefined. For example:

<div tts:fontSize="1c">
   <p tts:fontSize="100% 100%">...</p>
</div>

In this case the div sets a font size defined by height alone, so width is undefined. Then the first (horizontal) 100% value in the p element's tts:fontSize attribute is 100% of an unknown value. This cannot meaningfully be transformed by a transformation processor.

Solution proposals:

1. Prohibit two value percentage based sizes (simplest solution)
2. Prohibit two value percentage based sizes when the parent element's font size has a single value (harder to verify)
3. Define the applicable size to use when calculating the horizontal component of a two value percentage based font size if the parent element font size has a single value. (most complicated solution)

I would prefer the first of these on first look.

[skynavga]

On Fri, Oct 14, 2016 at 9:48 AM, Nigel Megitt notifications@github.com wrote:

If a two value percentage based tts:fontSize is used and an ancestor element specifies a single value absolute size, the horizontal component is undefined. For example:

...

In this case the div sets a font size defined by height alone, so width is undefined.

Not true. Specifying a single length is equivalent to specifying two lengths with the same value.

Then the first (horizontal) 100% value in the p element's tts:fontSize attribute is 100% of an unknown value. This cannot meaningfully be transformed by a transformation processor.

Solution proposals:

1. Prohibit two value percentage based sizes (simplest solution)
2. Prohibit two value percentage based sizes when the parent element's font size has a single value (harder to verify)
3. Define the applicable size to use when calculating the horizontal component of a two value percentage based font size if the parent element font size has a single value. (most complicated solution)

I would prefer the first of these on first look.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/ttml2/issues/200, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXCbwUPnUHlJa95hVQHQQq4F5l1LQXBks5qz6RpgaJpZM4KXKEY .

[skynavga]

Citing TTML1 (tts:fontSize):

If a single value is specified, then this length applies equally to horizontal and vertical scaling of a glyph's EM square ...

Therefore, your premise is false. Closing.

[nigelmegitt]

In this case the div sets a font size defined by height alone, so width is undefined. Not true. Specifying a single length is equivalent to specifying two lengths with the same value.

That cannot be right otherwise the cell size would effectively stretch the em square, which I don't believe it does. You would get a difference in rendered text just by changing the number of columns in ttp:cellResolution, which I do not believe is the case for tts:fontSize="1c" but is the case for a two value font size such as tts:fontSize="1c 1c".

[skynavga]

You are confusing specified value with computed value. When resolving percentages on children, the computed value of the parent is used. In this case '1c' has been resolved to a specific pixel value, so the inherited value is no longer in terms of cells.

[nigelmegitt]

Citing TTML1 (tts:fontSize):

If a single value is specified, then this length applies equally to horizontal and vertical scaling of a glyph's EM square ...

Exactly, in other words the glyph's em square size is defined by the height of 1c and not the width for single value font sizes, but by the height of 1c and the width of 1c independently for two value font sizes.

The equivalent width of a single value font size is unknown to a transformation processor since that can only be expressed in terms of the cell size and depends on an unknown font metric.

[please stop closing this issue prematurely - I believe you have not understood the problem]

[nigelmegitt]

When resolving percentages on children, the computed value of the parent is used.

Where is this stated?

In this case '1c' has been resolved to a specific pixel value, so the inherited value is no longer in terms of cells.

No, this has nothing to do with specific pixel values, at least I have not seen anything in the spec to say that it does. It is all simply relative to the parent element's font size. In any case the point stands that a single value font size of 1c resolves to a height and the font size is in terms of that height; no width value is available to a transformation processor at this point from which to calculate a relative percentage value.

[skynavga]

And I believe your premise is false. By the time the child is evaluated, the parent's font size has already been resolved to a fixed number of pixels in both height and width. Therefore, a child with font size "100% 100%" is always well defined.

[nigelmegitt]

How has a transformation processor made this resolution in the absence of a concrete font?

[skynavga]

Regarding use of computed value of parent, you have to understand XSL-FO and CSS2 where this is fully delineated. We did not repeat all semantics found there.

Second, with respect to transformation, some lengths cannot be resolved until rendering time. As a result, a transformation processor's target language must have an equivalent way to express the necessary abstractness required to make the eventual presentation time determination.

As for specifying a single value tts:fontSize='1c', this is equivalent to tts:fontSize='height(1c) height(1c)', which can be derived from:

When a single is expressed using cell units, then it refers to the height of the Computed Cell Size.

and

If a single value is specified, then this length applies equally to horizontal and vertical scaling of a glyph's EM square...

See also (under ttp:cellResolution):

Except where indicated otherwise, when a expressed in cells denotes a dimension parallel to the inline or block progression dimension, the cell's dimension in the inline or block progression dimension applies, respectively.

In the above case (of tts:fontSize), this would be a place where "except where otherwise indicated" applies.

[nigelmegitt]

I have hit this problem with a concrete example where the target language is TTML.

This transformation is the combination of two distinct TTML documents that cannot be relied upon to have the same ttp:cellResolution therefore a canonical representation is needed. Pixel extents are absent entirely. The canonical representation cannot be formed in the case raised by this issue. There is no option at this stage to defer until rendering.

I have never read the text

If a single value is specified, then this length applies equally to horizontal and vertical scaling of a glyph's EM square...

as saying anything other than that at rendering time the font is scaled isomorphically. It does not reveal anything in any meaningful units of the document instance about what horizontal size of the em square would result. It certainly does not appear to say that the em square of the font shall be scaled widthways to be the same as the width of 1c, and no implementation behaves that way, thankfully.

[skynavga]

BTW, on use of computed value from parent, CSS2.1 has:

On all other properties, 'em' and 'ex' length values refer to the computed font size of the current element. On the 'font-size' property, these length units refer to the computed font size of the parent element.

In our case, '%' is basically the same as 'em'. So 50% on child means 0.5em where em is computed size of parent's font size.

[nigelmegitt]

Now I'm really puzzled. It is clearly stated that % relates to the cell size not em in this case. Absolute units of em are not part of this issue.

[skynavga]

Where do you see that % relates to cell size? BTW, you should also review [1].

[1] https://www.w3.org/TR/ttml1/#semantics-style-resolved-value-category-computed

[nigelmegitt]

This issue is defined in terms of % relating to cell size since that's how the parent element's fontSize is defined; in general if no parent element specifies a font size then it is also related to the cell. The em unit is the result of computing the fontSize, not the source of it. I understand that for a presentation processor one would evaluate the parent element's font size and then apply the % to that; but for a transformation processor this is not an available option.

There's a related question here that may be helpful to clarify: in the text at https://www.w3.org/TR/ttml1/#style-attribute-fontSize:

if two <length> values are specified, then the first expresses the horizontal scaling and the second expresses vertical scaling.

it is not clear if this scaling is done according to the numerical value of the units provided or in the resolved computed size that results. In other words, there are (at least) these options for interpreting "1c 2c":

1. scale the em square by the numerical relationship of the c units independent of the cell's actual shape, in which case the em square would be stretched by a factor of exactly 2 horizontally.
2. make the em square exactly fit the 1c wide by 2c tall, regardless of the starting size of the em square.

I think option 2 is the correct interpretation, unless I have misunderstood, and of course at presentation time what that means depends on the aspect ratio of the root container region and the number of columns in cellResolution etc. In that case the equivalent horizontal % scaling value in relation to the cell can not be known at transformation time since there is too little information available.

The result of this seems to be that it is not possible deterministically to transform a TTML document with one cellResolution to a TTML document with a different cellResolution if this (commonly used) style of defining fontSize is used, i.e. that fontSize is defined as a % in relation to a cell size, in the specific case that a two value fontSize is used in relation to a one value parent fontSize specification. This is to my mind rather awkward, and undesirable. I'd be happy to be told that it is possible, but this thread has not given me cause to think so (yet).

[skynavga]

I think the first thing you need to understand is that percentage is only based on cell size in one and only one place: when a percentage is used with tts:fontSize on a region element. In this case, percentage is resolved with respect to the computed cell size, which is always measure in pixels in the document coordinate system. Further, the computed cell size (for a given document) is determined once and only once for a document, and that is at or prior to the beginning of the root temporal interval. Once the computed font size for region is determined in pixels, then that is the value inherited by descendant elements. In particular, descendant elements do not inherit cell based sizes or percentage sizes, they always inherit pixel based sizes.

Now, to resolve pixel based sizes, the document processing context must establish the document coordinate space and determine its resolution (width and height) in pixels. In other words, it must determine the storage aspect ratio and resolution of the root container region. This is clearly required for presentation processing; however, for transformation processing, this would be application specific. If the transformation processing involves the preservation of presentation semantics at some level, then it is likely that it will have to go through the same process as a presentation processor, i.e., establish a document coordinate space with a fixed pixel resolution. And, in order to do this, the transformation processor will need to establish any necessary parameters to facilitate its semantics.

In the example you describe, converting TTML documents between different cell sizes, it is clear that both the source and target will require a document coordinate space, and you will need to determine a transformation between these two spaces. As one would expect, this is outside the scope of TTML proper, as are the parameters one might need to support this.

[nigelmegitt]

... percentage is only based on cell size in one and only one place: when a percentage is used with tts:fontSize on a region element

My reasoning here is that if no font size is specified on a parent element then the style inheritance tree's root is the region, and if no region is specified there then the cell size is the basis for percentages. Since most documents I see do not specify style attributes on regions, but do so on style elements instead, referenced from descendants of the body, this is the general case that usually applies.

... percentage is resolved with respect to the computed cell size, which is always measure in pixels in the document coordinate system.

I disagree with this. There is no requirement to resolve the the computed cell size to pixels; such a requirement is not stated in the specification and it is not reasonable to require it in practice, especially in a transformation scenario.

the computed cell size (for a given document) is determined once and only once for a document, and that is at or prior to the beginning of the root temporal interval.

This is a statement that you made at the recent face to face meeting, which several people disagreed with. Again, it is neither a stated requirement nor a reasonable one; there is a clear counter example in which the root container region is associated with media that is resized during playback. This can be conceptually achieved at an arbitrary time during presentation simply by reevaluating the document in the context of the new processing context and re-displaying the currently active ISD.

Once the computed font size for region is determined in pixels, then that is the value inherited by descendant elements. In particular, descendant elements do not inherit cell based sizes or percentage sizes, they always inherit pixel based sizes.

Here, following, is my logic for disagreeing with this statement:

From computed style set processing:

replace the relative value of P with an equivalent, non-relative (computed) value;

and this is from the specified style set that was used to initialise the computed style set. So we are here processing relative styles in relation to the specified style of the parent, according to the only text that relates to fontSize, being:

Percentages: if not region element, then relative to parent element's font size; otherwise, relative to the computed cell size

And computed cell size is a defined term:

The size (extent) of a cell computed by dividing the width of the root container region by the column count, i.e., the number of cells in the horizontal axis, and by dividing the height of the root container region by the row count, i.e., the number of cells in the vertical axis, where the column and row counts are determined by the ttp:cellResolution parameter attribute.

This does not in any sense refer to pixels. It is reasonable to expect to be able to calculate this for example as a percentage width and height of the root container region without resolving it further.

My reading of this altogether is that the current specification text leads the reader to expect to be able to calculate the value of a percentage font size in terms of the specified font size (regardless of unit) of the parent element, if present, or if no ancestor and the region does not specify a font size, then this is related to the cell size.

So although mapping to pixels on a graphics plane is needed for a presentation processor to render text, the requirement to map to pixels is not a requirement in any other sense, and does not help to answer this question.

Regardless, if the answer truly is that transformation processors cannot map two value percentage font sizes related to single value parent element font sizes without a presentation processing context, then we should recognise this in some way, either by adding a semantic or syntactic restriction, or noting the limitation. Profile specifications may choose to address this if this transformation scenario is important.

[skynavga]

My reasoning here is that if no font size is specified on a parent element then the style inheritance tree's root is the region, and if no region is specified there then the cell size is the basis for percentages. Since most documents I see do not specify style attributes on regions, but do so on style elements instead, referenced from descendants of the body, this is the general case that usually applies.

It is correct that if no content element or region in the inheritance hierarchy specifies font size, then the initial value used by the region is '1c'; however, in this case, the computed value of the region's font size is (height,width), where width = height = (height of root region in pixels/number of rows in cell grid). And it is this computed value that is inherited by all content elements unless they happen to specify a font size.

percentage is resolved with respect to the computed cell size, which is always measure in pixels in the document coordinate system.

I disagree with this.

Then you need to read the spec more carefully. From TTML1 we have:

Computed Cell Size

The size (extent) of a cell computed by dividing the width of the Root Container Region by the column count, i.e., the number of cells in the horizontal axis, and by dividing the height of the Root Container Region by the row count, i.e., the number of cells in the vertical axis, where the column and row counts are determined by the ttp:cellResolution parameter attribute.

and

If the tts:extent attribute is specified on the tt element, then it must adhere to 8.2.7 tts:extent, in which case it specifies the spatial extent of the Root Container Region in which content regions are located and presented. If no tts:extent attribute is specified, then the spatial extent of the Root Container Region is considered to be determined by the Document Processing Context.

The extent of the root container region is always defined in pixels. Therefore, the computed cells size is always defined in pixels.

We also have the following example under ttp:cellResolution which clearly makes use of this fact:

For example, if padding (on all four edges) is specified as 0.1c, the cell resolution is 20 by 10, and the extent of the Root Container Region is 640 by 480, then, assuming top to bottom, left to right writing mode, the start and end padding will be (640 / 20) * 0.1 pixels and the before and after padding will be (480 / 10) * 0.1 pixels.

And the following example under ttp:texxtOutline:

When a expressed in cells is used in a tts:textOutline value, the cell's dimension in the block progression dimension applies. For example, if text outline thickness is specified as 0.1c, the cell resolution is 20 by 10, and the extent of the Root Container Region is 640 by 480, then the outline thickness will be a nominal 480 / 10 * 0.1 pixels, i.e., 4.8px, without taking into account rasterization effects.

All implementations of TTML that I am familiar with, including 3 that I personally implemented, follow this definition of computed cell size and were tested against this usage.

the computed cell size (for a given document) is determined once and only once for a document, and that is at or prior to the beginning of the root temporal interval.

This is a statement that you made at the recent face to face meeting, which several people disagreed with. Again, it is neither a stated requirement nor a reasonable one; there is a clear counter example in which the root container region is associated with media that is resized during playback. This can be conceptually achieved at an arbitrary time during presentation simply by reevaluating the document in the context of the new processing context and re-displaying the currently active ISD.

It may be possible to relax this constraint, but only in the case that tts:extent is not specified on the root element. If it were relaxed, then each time the extent/resolution of the root container region is changed, a new (possibly different) document coordinate space would have to be determined, and the computed cell size would have to be re-computed (in pixels). So in all cases, computed font sizes are in pixels (or possibly in some proxy for pixels).

replace the relative value of P with an equivalent, non-relative (computed) value;

and this is from the specified style set that was used to initialise the computed style set. So we are here processing relative styles in relation to the specified style of the parent, according to the only text that relates to fontSize, being:

Unfortunately, you have missed a step in the description of specified style processing, namely step 6(c):

if the element type of E is a Content element type or anonymous span, then set P′ to the result of looking up the value of P in the computed style set of the immediate ancestor element of E, i.e., CSS(PARENT(E));

So, one always inherits the computed value from the parent, in which case, relative values have been converted into an absolute form.

Perhaps this is the first time you are trying to figure out the (admittedly complex) style processing semantics. I can assure you from working with CSS, XSL-FO, and TTML1 implementations, that what I say here is correct.

[skynavga]

Also, regarding:

Regardless, if the answer truly is that transformation processors cannot map two value percentage font sizes related to single value parent element font sizes without a presentation processing context, then we should recognise this in some way, either by adding a semantic or syntactic restriction, or noting the limitation.

If you are suggesting that it should be possible to translate relative lengths in one document to relative lengths in another document where the basis for resolving these relative lengths varies, then my position is that this is certainly possible, and merely depends on supplying the necessary parameters (to the transformation process) that are needed to translate the relative lengths. The necessary parameters are the resolution (in logical pixels/units) of the root container region of the source and target documents as well as a linear transform and rounding rules that apply when converting coordinates.

Little else would be necessary, for example, fonts aren't needed, nor is layout processing.

Having said this, I don't see this as being a limitation or something that even requires addressing in TTML. I view it as an (transformation) application specific problem, and not a TTML issue.

[skynavga]

See also CSS 2.2 on Inheritance:

When inheritance occurs, elements inherit computed values. The computed value from the parent element becomes both the specified value and the computed value on the child.

[palemieux]

Looking back at the original comment.

In this case the div sets a font size defined by height alone, so width is undefined.

Section 8.2.9 of TTML1 specifies that If a single <length> value is specified, then this length applies equally to horizontal and vertical scaling of a glyph's EM square, so I would think that the computed width is "1c".

Then the first (horizontal) 100% value in the p element's tts:fontSize attribute is 100% of an unknown value.

Section 8.2.9 of TTML1 specifies that if not region element, then relative to parent element's font size, but does not explicitly state that it is relative to computed parent element's font size. Section 7.9.4 of XSL repeats a percentage value specifies an absolute font size relative to the parent element's font size, but Section 5.9.7.1 states a value of 110% on a font-size property would be evaluated to mean 1.1 times the current font size but does not define current font size.

What about explicitly stating that both 'em' and '%' are relative to the computed font size of the parent element?

[skynavga]

What about explicitly stating that both 'em' and '%' are relative to the computed font size of the parent element?

That would be a reasonable enhancement. I believe we did not explicitly state this at the time since we all (at the time TTML1 was created) already assumed this to be the case due to XSL-FO and CSS semantics.

[nigelmegitt]

Thanks, this has been an informative thread. Probably time to begin drawing it to a close.

In addition to @palemieux 's proposal above, I'd also suggest that there are two other areas that would benefit from a clarification:

Scaled vs absolute fontSizes on region element

The two items of text in tts:fontSize where

1. percentages are "if not region element, then relative to parent element's font size; otherwise, relative to the computed cell size" and
2. in the paragraph immediately beneath the table, the text suggests that the length "applies to scaling".

can be read as being contradictory or unclear.

The issue I have in interpreting this text is that I am unsure if it is saying that percentage value font sizes on a region element mean either "scale the font's em square horizontally in proportion to the height of a cell and vertically in proportion to the width of a cell" or "scale the font's em square vertically in proportion to the height of a cell and horizontally in proportion to the height of a cell". In other words, are percentages in this context scaling factors or absolute values that need to result?

For example, does a value "100% 100%" result in an em square that is scaled anamorphically to the width of 1c and the height of 1c or in an em square that is the height of 1c and the unscaled width of the em square of that height as defined by the font? (NB I'm deliberately not assuming that the em square is in fact square - see the loose end regarding superscript and subscript at the end of this post to understand why)

I think a reasonable and useful but not necessarily intuitive interpretation would be:

• "100%" implies "height = height of 1c, width as defined by font for that height" and
• "100% 100%" implies "height = height of 1c, width = width of 1c".

Computed value calculation

It would be helpful to clarify further in step 4 of Computed Style Set Processing that the text in Computed Values applies when evaluating relative values, for example by changing:

a. replace the relative value of P with an equivalent, non-relative (computed) value;

to:

a. replace the relative value of P with an equivalent, non-relative value computed by applying the relative value to the computed value of the basis;

Loose ends

I would like to be able transform TTML documents in a truly resolution independent way; it seems that this is not possible right now and that some information is needed including the (logical) pixel extent of the root container region, which in general is not available until presentation time. I'm curious to know if this means that mapping to e.g. SVG is implementation dependent, or not truly scalable.

When scaling horizontally or perhaps more precisely, glyph-fitting to a cell, there's an argument that we have the wrong unit and that the semantic should be to scale the font such that 1ch fits in the specified size (width or height depending on writing direction), since that includes the advance measure. For the original intended use case of anamorphic font scaling, namely double height teletext characters, this was not an issue since each glyph in the bitmap font included the advance space and those glyphs could be laid out in a tile-based fashion. (personally I have no appetite for changing this; it's just an observation)

Do we have to deal with non-square em squares and font sizing for superscript and subscript values of ttp:fontVariantPosition? Superscript and subscript em squares are not necessarily square and their widths can be defined independently to their heights - see https://www.microsoft.com/typography/otspec/mvar.htm for example.

[skynavga]

If a user specifies

<region tts:fontSize="100% 100%"/>

Then the computed value of tts:fontSize for the region is the tuple (100% * width(CCS),100% * height(CCS)), where CCS means computed cell size.

If a user specifies

<region tts:fontSize="100%"/>

Then the computed value of tts:fontSize for the region is the tuple (100% * height(CCS),100% * height(CCS)).

The specification basis for this interpretation is the fourth Note in TTML1 §8.2.9:

Note: The expression 1c means one cell, where 'c' expresses the cell length unit as defined by 8.3.9 . When a single is expressed using cell units, then it refers to the height of the Computed Cell Size. When two values are expressed using cell units, then the first refers to the width of the Computed Cell Size, and the second refers to the height of the Computed Cell Size.

Under normal circumstances, this would have been normative text, but it was made as a late change to TTML1 and expressed as a note in order to avoid the appearance of making a substantive change. In TTML2, we need to upgrade this interpretation to normative status.

Regarding

"100%" implies "height = height of 1c, width as defined by font for that height"

The first part "100%" implies "height = height of 1c" is correct, but the last part is based on a possible misunderstanding of a font's EM square. A font's EM square is always square; therefore, it is not dependent on "width as defined by font". Note that the following equation holds for fonts for all i where i is any glyph index employed by a font:

width(EM SQUARE) = lsb(glyph(i)) + advance(glyph(i)) + rsb(glyph(i))

where, lsb := left side bearing, advance := horizontal advance, rsb := right side bearing.

So, the single value "100%" for font size (on region) means that both width and height of the scaled EM square is equal to the height of the computed cell size.

While "100% 100%" means width of the scaled EM square is width of computed cell size and height of the scaled EM square is the height of the computed cell size. Keep in mind that the first percentage refers to the horizontal (width) and the second percentage refers to the vertical (height) of the scaled EM square.

Regarding

It would be helpful to clarify further in step 4 of Computed Style Set Processing that the text in Computed Values applies when evaluating relative values, for example by changing:

a. replace the relative value of P with an equivalent, non-relative (computed) value;

to:

a. replace the relative value of P with an equivalent, non-relative value computed by applying the relative value to the computed value of the basis;

This is a problematic change because it introduces relative value processing into the algorithm which depends upon the semantics of individual style properties. It is better to specify such processing in a more local context, i.e., in individual style property definitions.

Regarding transformation of documents that use cell size in a resolution independent manner, that would seem feasible if CCS were expressed in root container relative dimensions rather than pixels, i.e., using TTML2 rw and rh units only. For example, if the source document uses the default ttp:cellResolution="32 15", then CCS would be the pair ((100/32)rw, (100/15)rh), or (3.125rw, 6.667rh).

If, for sake of example, the target document reverses the cell resolution, i.e., tts:cellResolution="15 32", then the CCS of the target document is (6.667rh, 3.125rw).

Now to convert between root container relative measure from source to target document, you need to specifying scaling factors in both width and height, depending on how you want the target cell geometry to correspond to the source cell geometry. And this will depend on application specific semantics, such as:

• is the display aspect ratio of the root container of both source and target to be preserved?
• is the display aspect ratio of the cell geometry of both source and target to be preserved?

Ultimately, you would need to determine an sf(x) and sf(y), then multiply these scale factors by coordinates and extents expressed in root container relative terms in the source document to determine the corresponding coordinates and extents expressed in root container relative terms in the target document.

I don't see any barrier to doing this, so I conclude that it is indeed possible to transform between TTML documents in a resolution independent manner.

Regarding

When scaling horizontally or perhaps more precisely, glyph-fitting to a cell, there's an argument that we have the wrong unit and that the semantic should be to scale the font such that 1ch fits in the specified size (width or height depending on writing direction), since that includes the advance measure.

I'm not sure what you mean by glyph fitting to a cell, since this is expressly not part of the semantics of cell in TTML1 §6.2.1:

Note: The use of a uniform grid is employed only for the purpose of measuring lengths and expressing coordinates. In particular, it is not assumed that the presentation of text or the alignment of individual glyph areas is coordinated with this grid. Such alignment is possible, but requires the use of a monospaced font and a font size whose EM square exactly matches the cell size.

[nigelmegitt]

Regarding

It would be helpful to clarify further in step 4 of Computed Style Set Processing that the text in Computed Values applies when evaluating relative values, for example by changing:

a. replace the relative value of P with an equivalent, non-relative (computed) value; to:

a. replace the relative value of P with an equivalent, non-relative value computed by applying the relative value to the computed value of the basis;

This is a problematic change because it introduces relative value processing into the algorithm which depends upon the semantics of individual style properties. It is better to specify such processing in a more local context, i.e., in individual style property definitions.

I do not understand this comment - from what you have written above it is already in the algorithm but just not clearly stated. The text I propose says nothing about how the relative value processing is done, or indeed what the basis is: I agree that those should be in the local context, as they already are.

My goal in adding this text is to make it absolutely clear that relative value computation is done based on a computed value; right now it is quite easy to miss this point since it is held in text in other sections.

[nigelmegitt]

Regarding

When scaling horizontally or perhaps more precisely, glyph-fitting to a cell, there's an argument that we have the wrong unit and that the semantic should be to scale the font such that 1ch fits in the specified size (width or height depending on writing direction), since that includes the advance measure.

I'm not sure what you mean by glyph fitting to a cell, since this is expressly not part of the semantics of cell in TTML1 §6.2.1:

Note: The use of a uniform grid is employed only for the purpose of measuring lengths and expressing coordinates. In particular, it is not assumed that the presentation of text or the alignment of individual glyph areas is coordinated with this grid. Such alignment is possible, but requires the use of a monospaced font and a font size whose EM square exactly matches the cell size.

Yes, okay, point taken, I mean that if the author's goal is to have each glyph fit within a specified number n of cells horizontally so that m "characters" fit in nm cells then the more useful unit is not em but ch.

[nigelmegitt]

One further point that may be worth clarifying, perhaps with an example, and that may not be at all obvious to some readers at first reading:

The following two examples result in different behaviour:

Example 1 : Percentage fontSize on region

<head>
   <layout>
      <region xml:id="r0" tts:fontSize="100% 100%">
   </layout>
</head>
<body>
   <div>
      <p region="r0">Some text</p>
   </div>
</body>

Example 2 percentage fontSize on p with no parent element fontSize set

<head>
   <layout>
      <region xml:id="r0">
   </layout>
</head>
<body>
   <div>
      <p region="r0" tts:fontSize="100% 100%">Some text</p>
   </div>
</body>

In Example 1, the computed font size of the region and therefore the p and its text has width = width of 1c and height = height of 1c.

In Example 2, the computed font size of the region has width = height = height of 1c, and the computed font size of the p and its text has width = height of 1c and height = height of 1c.

This should go in a "surprising results" note!

[palemieux]

To summarize,

• "Yc" means that both the em square height and width are both equal to Y times the computed height of a cell, so tts:fontSize="<normalized_computed_height_of_a_cell>rh <normalized_computed_height_of_a_cell>rh"
• "Xc Yc" means that the em square height equals Y times the computed height of a cell and the em square width equals X times the computed width of a cell, tts:fontSize="<normalized_computed_width_of_a_cell>rw <normalized_computed_height_of_a_cell>rh"

where <normalized_computed_height_of_a_cell> = 100 / cellResolution.rows and <normalized_computed_width_of_a_cell> = 100 / cellResolution.columns.

The actual height and width of a cell in pixels can computed once the root container has been mapped to an actual pixel array/grid.

[nigelmegitt]

That's my understanding, yes, when you specify font size using cell units.

A minor point: if you're going to reuse that summary anywhere @palemieux you might switch X and Y everywhere in the second bullet so that in the two value variant you use "Xc Yc" since the first value is a horizontal measure and the second a vertical one, and X and Y are often used to indicate those axes.

[skynavga]

On Fri, Oct 21, 2016 at 9:58 AM, Pierre-Anthony Lemieux < notifications@github.com> wrote:

To summarize,

-

"Xc" means that both the em square height and width are both equal to X times the computed height of a cell, so (inventing a new metric) tts:fontSize="rh

rh" - "Yc Xc" means that the em square height equals X times the computed height of a cell and the em square width equals Y times the computed width of a cell, tts:fontSize="rw rh" where = 100 / cellResolution.rows and = 100 / cellResolution.columns. The actual height and width of a cell in pixels can computed once the root container has been mapped to an actual pixel array/grid.

Basically correct. If I had written this, I would have first determined the computed cell size, which will be in pixels if tts:extent is specified or if not specified and the document processing context supplies a default in pixels; otherwise, the document processing context may use root container relative lengths in the computed cell size. Saying it this way allows you get rid of the language about normalized lengths.

Also, I agree with Nigel that "Yc Xc" or even better "Wc Hc" would be better than "Xc Yc".

[skynavga]

Discussed in meeting and agree to addresss:

• improved language around use of computed value
• improved language around use of relative value resolution, including material on possible use of root container relative units, and also EM
• adding "surprise results" example
• addressing improvements to ttp:cellResolution about references to dimensions of cell (height only or width and height)

[skynavga]

P.S. Also note that references to EM always resolve to height of EM, even in width referencing contexts.

[GA - 05/25/17 - the above sentence is misleading or wrong in certain contexts]

[nigelmegitt]

I'm not happy with the merge here - it happened mid-discussion.

[skynavga]

[Meeting 06/01/17] GA provided a detailed review of the treatment of font coordinate spaces and how a font's EM square coordinate space is mapped to logical pixels (in TTML terms) used to perform layout processing, which logical pixels are subsequently mapped to display pixels where glyph rasterization is performed. If a font size is specified as a single value, then that value applies to both the height and width of the EM square in logical pixels, but if specified as two values, then those values apply independently to height and width of EM square. Layout processing then occurs according to these logical pixels, including decisions about line breaking. Even documents that solely use percentages are (notionally) performing layout in such logical pixels based on an (arbitrary) resolution assigned by the document processing context.

The conclusion of this discussion was that no further changes are required for this PR; however, GA noted that he intends to define "logical pixels" and "display pixels" in the terminology section and that he will add notes indicating that (1) all reference to pixels refer to logical pixels unless otherwise noted, and (2) all layout processing is performed in logical pixels (using the document coordinate space).

[nigelmegitt]

Thanks for the summary @skynavga . We also touched briefly on the idea of using rh for a canonical unit of width in certain circumstances. I would like a clearer example showing how a transformation processor can usefully deal with single value font sizes in the absence of a defined root container region extent as a canonical value in rh units for both height and width. I am happy to try to put that example together, even though that does seem like a somewhat intrepid exercise to embark upon...