Update tts:lineHeight='normal' algorithm to match TTML2

[palemieux]

Closes #354

[andreastai]

My review of the algorithm comes late. So, my comments are non-blocking to not interfere with the publication process.

I have some concerns. The recommended algorithm assumes that a presentation processor has access to the font properties of a font file when it calculates the resolved computed value. I doubt that this is the case.

This is also not an algorithm defined in CSS. To be more compliant with CSS one option would be to take the (very vague) text from CSS 2.1.

If a change is not possible, some terms in the algorithm may need to be clarified. What is the reference for the terms altitude and descent? To be clear some terms from a font format as open type should be used instead. This can be then used as reference for equivalent font formats.

[css-meeting-bot]

The Working Group just discussed Update tts:lineHeight='normal' algorithm to match TTML2 ttml1#355, and agreed to the following:

• SUMMARY: @skynavga to make an editorial tweak from altitude to ascent in TTML2 and @palemieux to port that back into this pull request; @skynavga to raise an issue to add the special inheritance semantics back into TTML2.

The full IRC log of that discussion

<nigel> Topic: Update tts:lineHeight='normal' algorithm to match TTML2 ttml1#355
<nigel> github: https://github.com/w3c/ttml1/pull/355
<nigel> Nigel: See discussion above in the [minutes from this meeting](https://www.w3.org/2018/07/12-tt-minutes.html) by the way.
<nigel> Pierre: Nigel you raised the point about the note being removed.
<nigel> Nigel: Yes, thank you for the reminder. This is about the note that helpfully explained that
<nigel> .. using lineHeight="125%" and fontSize="0.8c" could be used to get lines that fit in 1c
<nigel> .. height.
<nigel> .. The current pull request removes that note, and I wanted to put it back.
<nigel> Pierre: As we know the actual space between line boxes is not guaranteed to be the
<nigel> .. specified value of lineHeight. My conclusion is that for folks that expect to be able
<nigel> .. to reproduce the exact grid they were accustomed to in old systems that cannot be
<nigel> .. done reliably. You can get close most of the time.
<nigel> Glenn: You can construct scenarios where it can be made so, for example by making
<nigel> .. none of the descendant elements specify a font size at all. To try to explain in a note
<nigel> .. this very complicated subject I would prefer to leave the note out. I'm not inclined
<nigel> .. to add it back in.
<nigel> Andreas: My view is similar to what Pierre said - the value "normal" interpretation is
<nigel> .. messed up. I think it is not really necessary to repeat the note, because if you go
<nigel> .. from a grid based layout to TTML then there may be another specification like EBU-TT
<nigel> .. that could point out the possible use of 125% for that reason.
<nigel> .. I still think that it could be good advice for some transformation to recommend
<nigel> .. transforming grid based layouts to TTML and back, although you cannot guarantee
<nigel> .. the same presentation. It is still a valid recommendation but it does not have to be in
<nigel> .. TTML.
<nigel> Nigel: Okay, I'm not going stick this one out and have recorded that I feel we have lost
<nigel> .. something helpful.
<nigel> .. Let's conclude not to add the note back in now.
<nigel> .. Moving on to the next point about resolved computed vs computed, Glenn you had a point:
<nigel> Glenn: We can't remove the "resolved computed value" and go back to "computed value"
<nigel> .. because the "computed value" is the inherited value and the special inheritance semantics
<nigel> .. dictate that the computed value is inherited. We can only talk about the algorithm
<nigel> .. to produce the actual lineHeight to take into account the input and the output value.
<nigel> .. I used the phrase "resolved computed value" which seemed like the best option without
<nigel> .. adopting "used value" as per CSS which is not used in XSL-FO.
<nigel> .. As to adding the special inheritance section note, Pierre is correct that we should have
<nigel> .. added it in to TTML2 but failed to do that.
<nigel> Nigel: I read it a different way, namely that the text changes removed the need for that
<nigel> .. special inheritance semantics section.
<nigel> Glenn: You might be right in part.
<nigel> .. It is not entirely clear.
<nigel> .. CSS actually explicitly says it whereas XSL-FO marginally says it, in one place but not another.
<nigel> .. It's indirect in §4.5 under line areas. It's not bad to have the explicit section on
<nigel> .. special inheritance here. Since we could not add it normatively in TTML2 CR2 we had
<nigel> .. to resort to a note.
<nigel> Nigel: Okay, I had read it a different way and Pierre and Glenn think the special inheritance
<nigel> .. section is useful. I don't think it is harmful just that we had cleverly avoided the need
<nigel> .. for some unnecessary spec text.
<nigel> .. I am happy to keep it. We should have an issue on TTML2 to add it back in.
<nigel> Glenn: I can add that issue and mark it as ttml.next.
<nigel> Nigel: Okay that works for me.
<nigel> SUMMARY: @skynavga to make an editorial tweak from altitude to ascent in TTML2 and @palemieux to port that back into this pull request; @skynavga to raise an issue to add the special inheritance semantics back into TTML2.