Re: line-height: normal and multiple descendant font sizes

On Fri, Oct 18, 2013 at 9:58 AM, John Hudson <tiro@tiro.com> wrote:

> On 17/10/13 10:34 PM, Glenn Adams wrote:
>
>  Actually, the spec means font size not font [family] when it says
>> rendered in more than one font. Otherwise, it wouldn't say the largest
>> font*size*. Font family is not related to line height computation.
>>
>
> It is if the line height is being computed from in-font metrics (OS/2
> WinAscent and WinDescent values, OS/2 Typo values, or corresponding hhea
> table values), which is what the line-height spec indicates. I presumed
> that the spec in this instance meant 'largest vertical metrics' when it
> says 'largest font size', but agree that this could be clearer.
>

My interpretation of "largest font size" is one of:

#1 max(computedFontSize(B), computedFontSize(I1), ..., computedFontSize(I*n*
))

or

#2 max(computedFontSize(I1), ..., computedFontSize(I*n*))

where B is the block element and I1...I*n* are its inline children elements.

And where computedFontSize(E) is the result of the normal CSS cascading and
computed style resolution process.

What I am observing, however, is that font size appears to be interpreted
on a per-line basis in order to create a per-line value for line height.
This appears to be counter to the language in [1] that says:

"Still for each glyph, determine the leading L to add, where L =
'line-height' <http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height>
 - AD. Half the leading is added above A and the other half below D, giving
the glyph and its leading a total height above the baseline of A' = A + L/2
and a total depth of D' = D + L/2."

In this language, it is clear that line-height is an input parameter for
computing leading L. For it to be an input parameter, it must have been
assigned prior to determining any L for any glyph on any line generated by
the block. The only way it could be assigned beforehand is by using the CSS
cascading computed values for some combination of the block element and its
child elements.

[1] http://www.w3.org/TR/CSS2/visudet.html#leading





>
> This is a topic discussed at some length during development of the
> Composite Font Representation (ISO/IEC 14496-28:2012), and as in that case
> the only safe method is to use the largest individual metrics values from
> each of the fonts involved (bearing in mind that metrics may affect not
> only line height but also glyph clipping zones). This means that the
> appropriate above-baseline metric and below-baseline metric may come from
> different fonts in the line, especially if different writing systems are
> involved. For example, combining Vietnamese and Burmese text on the same
> line will almost certainly require taking the ascender height from the
> Vietnamese font and the descender depth from the Burmese font, because of
> the way in which these two writing systems make use of vertical space.
>
> JH
>
>