Does half-leading apply to a line-area?

[andreastai]

Section 11.3.2.2 - Line Stacking Strategy

• Note well that the half leading applied to a line area and the half leading applied to an inline area child of that line area are often distinct values,

I doubt that there is half leading applied to the line area at all. Regarding line area construction it is only applied to inline areas.

This needs to be clarified. If the assumption is correct this needs to be amended in the Spec.

[skynavga]

I believe that each line area has a half-leading that is independent of the half-leading of each inline area child. I will document the rationale for my position in a subsequent comment.

[skynavga]

Per [XSL-FO] §4.5 [1], the expanded-nominal-requested-line-rectangle associated with a line area includes half-leading (emphasis added):

The expanded-nominal-requested-line-rectangle is the rectangle with start-edge and end-edge coincident with those of the nominal-requested-line-rectangle, and whose before-edge and after-edge are outside those of the nominal-requested-line-rectangle by a distance equal to the half-leading.

In contrast, the distinct expanded-rectangle associated with a inline area child of a line area also includes half-leading (emphasis added):

The expanded-rectangle of an inline-area is the rectangle with start-edge and end-edge coincident with those of its allocation-rectangle, and whose before-edge and after-edge are outside those of its allocation-rectangle by a distance equal to either (a.) the half-leading, when the area's allocation-rectangle is specified to be the normal-allocation-rectangle by the description of the generating formatting object , or (b.) the space-before and space-after (respectively), when the area's allocation-rectangle is specified to be the large-allocation-rectangle.

Although the specification text cited here does not make it clear that the first use of half-leading is distinct from the second use of half-leading, that must logically follow from the definition of half-leading, which is defined, in [XSL-FO] §6.5.2 [2] as

The .minimum, .optimum, and .maximum components of the half-leading trait are set to 1/2 the difference of the computed value of the line-height property and the computed value of the sum of the text-altitude and text-depth properties. The .precedence and .conditionality components are copied from the line-height property.

Now, if one looks at this text alone, one might come to the (IMO wrong) conclusion that all half-leading values are tied to block areas, e.g., a line area or its parent block area; however, there is something essential missing here, which is that the line-height property applies independently to fo:block, fo:inline-container, fo:inline, and fo:character, etc. Furthermore, the text-altitude and text-depth properties differ between a fo:block and its constituent inline objects since different font binding and font size properties apply.

As a consequence, the computation

half-leading := line-height - (text-altitude + text-depth)

must, by necessity, vary between a line area and inline area children of the line area. In particular, the half-leading of a line area and its children inline areas will be the same only if they share the same line-height, text-altitude, and text-depth values.

While this latter condition will indeed apply in many cases, it will not apply as soon as the line-height, text-altitude, or text-depth of an inline object differs from its parent block object.

Note well the text in XSL-FO §4.6 [3]:

An inline-area has its own line-height trait, which may be different from the line-height of its containing block-area. This may affect the placement of its ancestor line-area when the line-stacking-strategy is line-height.

This interpretation is also reflected in the language in CSS2.2 §10.8.1 [4], though that language has some vagaries as well. Now, combine this with the explicit intention stated by XSL-FO §7.16.6 [5] that

This [the line-height line stacking strategy] matches CSS's line-height and positioning strategy.

So, regarding whether the language of XSL-FO or CSS applies to the line-height line stacking strategy, we must operate on the assumption that the explicit intention of XSL-FO was that the semantics match CSS, and, furthermore, if there are multiple readings of XSL-FO specification text that lead to different degrees of compatibility with this intention, then we must choose the reading that obtains the highest degree of compatibility.

In regards to some of the vagaries found in XSL-FO, I recently posted a message to the (now mostly inactive) XSL-FO Mail List [6], which is worth reviewing in the present context.

[1] https://www.w3.org/TR/2006/REC-xsl11-20061205/#area-line
[2] https://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_block
[3] https://www.w3.org/TR/2006/REC-xsl11-20061205/#area-inline
[4] https://drafts.csswg.org/css2/visudet.html#leading
[5] https://www.w3.org/TR/2006/REC-xsl11-20061205/#line-stacking-strategy
[6] https://lists.w3.org/Archives/Public/www-xsl-fo/2018Jun/0009.html

[andreastai]

@skynavga Thanks for detailed reasoning. This needs some proper review from my side. I will also try to test this with XSL-FO rendering application. In any case if we come to a conclusion there needs to be a transparent and understandable explanation how spacing based on line height is applied. In TTML the minimun, maximum and optimum components are never mentioned and it is not clear how this affects TTML.

[skynavga]

@TairT XSL-FO uses a more general treatment of length or distance dimension values, each of which has 5 components:

• minimum
• optimum
• maximum
• conditionality
• precedence

whereas, for TTML, length/distance dimension values have a single component.

Conversion between the two is as follows:

• From XSL-FO to TTML:
  • TTML.length = XSL-FO.optimum
• From TTML to XSL-FO (in general, but see definition of each XSL-FO property for exceptions):
  • XSL-FO.minimum = TTML.length
  • XSL-FO.optimum = TTML.length
  • XSL-FO.maximum = TTML.length
  • XSL-FO.conditionality = retain
  • XSL-FO.precedence = force

See XSL-FO §4.3 [1] for more info.

[1] https://www.w3.org/TR/xsl11/#spacecond

[skynavga]

@TairT could you propose a spec change or close this issue please

[andreastai]

@skynavga Thanks for the details.

I close this issue. See #859 (comment) for explanation.