Re: lineHeight

Let's add this to the agenda for tomorrow's call.


On Wed, Aug 28, 2013 at 1:24 PM, Andreas Tai <tai@irt.de> wrote:

>  Thanks, Glenn. I think this is a reasonable solution. After looking at
> the specs that map the legacy grid based subtitle formats to TTML maybe one
> small adjustment could be considered.
>
> As for example in SDP-US the font-size value of 100% or 1c was chosen
> under the assumption that the initial value of line-height is normal (=
> 100% of the font-size). Therefore a row that has content with a  font-size
> of 100% or 200% stays in the grid (if a mono spaced font was chosen) .
>
> Unless I made some wrong assumption this seems no longer be true with a
> line-height of 120%. Therefore the font-size has to be aligned with this
> new value to get the same semantics. With a line-height of 120% a
> font-size of approximately 83,34% has to be selected to fill a row with the
> height of 1c. But it could be clearer if the lineHeight would be set to
> 125% because then the corresponding font-size could be specified as 80%
> (for the height of 1c) or 160% (for the height of 2c).
>
> Best regards,
>
> Andreas
>
> Am 26.08.2013 21:06, schrieb Glenn Adams:
>
> Yes. I've already implemented the change in the TTML1SE ED at [1]. I view
> this as "comment resolution" of comments received during the PER review
> period, and have documented it in [2] (along with other post-PER edit
> changes).
>
>  [1]
> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1.html#style-attribute-lineHeight
> [2]
> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1-changes.html
>
>
>  On Mon, Aug 26, 2013 at 11:12 AM, Michael Dolan <mdolan@newtbt.com>wrote:
>
>>  I agree that this would be very helpful.  Just to confirm, you are
>> proposing it be a last minute edit to 1.0SE, right?
>>
>>
>>
>> *From:* Andreas Tai [mailto:tai@irt.de]
>> *Sent:* Sunday, August 25, 2013 6:37 AM
>> *To:* Glenn Adams
>>
>> *Cc:* TTWG
>> *Subject:* Re: lineHeight
>>
>>
>>
>> Thanks for the very prompt solution proposal, Glenn.
>>
>>
>>
>> Yes, personally I think this is the solution that is needed. It makes it
>> clearer and as you said it meets the expectation of authors that are coming
>> from CSS and XSL:FO.
>>
>>
>>
>>
>>
>> Am 23.08.2013 um 19:50 schrieb Glenn Adams:
>>
>>  How about we change the 8.2.12 (in TTML1) to read as follows?
>>
>>
>>
>> If the value of this attribute is normal, then the computed value of the
>> style property must be considered to be the same as 120% of the largest
>> font size that applies to the element and its descendant elements in the
>> intermediate synchronic document as determined by *9.3.2 Intermediate
>> Synchronic Document Construction*.
>>
>>
>>
>> This is basically equivalent to the 1.2 multiplier used by most existing
>> HTML browsers.
>>
>>
>>
>> Should we be considered about potentially breaking interoperability with
>> existing presentation processors? Since our existing TTML test suite does
>> not include reference image output, this change wouldn't alter test results
>> (as presently written). This change would also improve compatibility with
>> TTML and author expectations based on their use of line-height in HTML and
>> XSL-FO.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Aug 23, 2013 at 10:48 AM, Glenn Adams <glenn@skynav.com> wrote:
>>
>>
>>
>> On Fri, Aug 23, 2013 at 10:44 AM, Glenn Adams <glenn@skynav.com> wrote:
>>
>>
>>
>> On Fri, Aug 23, 2013 at 8:01 AM, Andreas Tai <tai@irt.de> wrote:
>>
>>  Thanks for the detailed walk through! It continues the discussion we
>> had in a thread before [1].
>>
>> To be clear that I got it right about the default value of line-height:
>> If the computed line-height is the same as the largest font-size of a
>> descendent and we assume the font-size of a p block is 14px for all
>> descendant elements, than the computed line height is 14px. If we assume
>> that the sum of the  computed values of the text-altitude and text-depth
>> properties is not less than 14px than the leading is 0 or negative. Is this
>> correct?
>>
>>
>>
>> Since we don't expose the XSL-FO text-{altitude,depth} properties, then
>> they will be determined according to font metrics, and it is a standard
>> assumption that their sum is the same as the EM cell height, namely, the
>> font size.
>>
>>
>>
>> So in your example, if the font size for the block itself and its
>> descendants are 14px and the line height on the block is 14px, then leading
>> is zero, and the line heigh of individual lines will be 14px as well.
>>
>>
>>
>>
>> If this is the case the default value for line-height would generate a
>> representation that is not very accessible.
>>
>>
>>
>> I guess you mean "not very readable".
>>
>>
>>
>>
>> I am not sure how much we can take the font-size/line-height dependency
>> in CSS as reference but at least here a two-line subtitle would not be very
>> readable if font-size and line-height have the same value (see
>> http://jsfiddle.net/tairt/YdsWd/).
>>
>>
>>
>> There are two options: you as an author can specify something else for
>> line height, say 120%. Or we can change the spec to say something else,
>> such as resolve 'normal' to 120% of the maximum descendant font size.
>>
>>
>>
>> That last part should better read as "resolve 'normal' to 120% of the
>> maximum of the current element and its descendants' font size".
>>
>>
>>
>>
>>
>>
>> Best regards,
>>
>> Andreas
>>
>> 1] http://lists.w3.org/Archives/Public/public-tt/2013Jul/0090.html<http://lists.w3.org/Archives/Public/public-tt/2013Jul/0090.html>
>>
>>
>>
>> -------- Original-Nachricht --------
>>
>> *Betreff: *
>>
>> Re: lineHeight
>>
>> *Weitersenden-Datum: *
>>
>> Fri, 23 Aug 2013 02:55:03 +0000
>>
>> *Weitersenden-Von: *
>>
>> public-tt@w3.org
>>
>> *Datum: *
>>
>> Thu, 22 Aug 2013 20:54:09 -0600
>>
>> *Von: *
>>
>> Glenn Adams <glenn@skynav.com> <glenn@skynav.com>
>>
>> *An: *
>>
>> Michael Dolan <mdolan@newtbt.com> <mdolan@newtbt.com>
>>
>> *Kopie (CC): *
>>
>> TTWG <public-tt@w3.org> <public-tt@w3.org>
>>
>>
>>
>> Thanks for asking, as this is a complex area of functionality when having
>> to wade through the more general models of both XSL-FO and CSS. See inline
>> below for clarifications and answers, and at the end some additional useful
>> information.
>>
>>
>>
>> On Thu, Aug 22, 2013 at 4:55 PM, Michael Dolan <mdolan@newtbt.com> wrote:
>>
>> Glenn and all-
>>
>>
>>
>> A cursory reading of TTML suggests lineHeight=fontSize.  But digging
>> deeper into XSL, one might reach different conclusions in red (also marked
>> “CONCLUSION”).
>>
>>
>>
>> [TTML 8.2.12]:
>>
>>  tts:lineHeight
>>
>> If the value of this attribute is normal, then the initial value of the
>> style property must be considered to be the same as the largest font sizethat applies to any descendant element.
>>
>> ….
>>
>> The semantics of the style property represented by this attribute are
>> based upon that defined by [XSL 1.1], § 7.16.4.
>>
>>
>>
>> First, we should quote the current TTML1 ED text, which was updated on
>> July 12th [1] and 16th [2] to read as follows:
>>
>>
>>
>> "If the value of this attribute is normal, then the computed value of
>> the style property must be considered to be the same as the largest font
>> size that applies to any descendant element in the intermediate synchronic
>> document as determined by *9.3.2 Intermediate Synchronic Document
>> Construction*<https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1.html#semantics-region-layout-step-1>
>> ."
>>
>>
>>
>> [1] https://dvcs.w3.org/hg/ttml/rev/00a9b799895d
>>
>> [2] https://dvcs.w3.org/hg/ttml/rev/0355e9473d7e
>>
>>
>>
>> This text, about the "largest font size", is intended to correspond to
>> the following language in:
>>
>>
>>
>> XSL-FO [3]:
>>
>>
>>
>> "When an element contains text that is rendered in more than one font,
>> user agents should determine the "line-height" value according to the
>> largest font size."
>>
>>
>>
>> [3] http://www.w3.org/TR/2006/REC-xsl11-20061205/#line-height
>>
>>
>>
>> and CSS2.1 10.8.1 [4]:
>>
>>
>>
>> "When an element contains text that is rendered in more than one font,
>> user agents may determine the 'normal' 'line-height'<http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height> value
>> according to the largest font size."
>>
>>
>>
>> [4] http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height
>>
>>
>>
>> Note that these two citations are identical except that CSS2.1 added
>> 'normal', while XSL-FO, which quotes CSS2, didn't make it explicit that
>> this sentence was to be scoped by interpretation of what 'normal' means.
>>
>>
>>
>> Note also the two changes [1][2] we made in TTML1 since PER:
>>
>>    - correct "initial value" to read "computed value";
>>    - clarify that "descendant element" refers to descendants in the
>>    intermediate synchronic document, and not the source document;
>>
>>  In other words, this changed language is about determining what the
>> computed value of 'normal' means, and which descendants apply in making
>> that determination. For example, one may have read the prior language as
>> including the font size of descendant elements that are not temporally
>> active or are selected into a different region, both of which should not
>> apply when resolving the computed value for 'normal'.
>>
>>
>>
>> [XSL 7.16.4]:
>>
>> Normal: Tells user agents to set the computed value to a "reasonable"
>> value based on the font size of the element. The value has the same meaning
>> as <number>. We recommend a computed value for "normal" between 1.0 to 1.2.
>>
>> <length>: The box height is set to this length.
>>
>>
>>
>> CONCLUSION: Therefore as TTML states that a value of "normal" "must be
>> considered to be the same as the largest font size", I assume that the XSL
>> 7.16.4 definition that is in effect is "<length>" with the value of the
>> largest font size.
>>
>>  Correct. For example, if one has:
>>
>>
>>
>> <p id="p1" tts:fontSize="12pt" tts:lineHeight="normal">
>>
>> <span tts:fontSize="10pt">FOO</span>
>>
>> <span tts:fontSize="12pt">BAR</span>
>>
>> <span tts:fontSize="14pt">BAZ</span>
>>
>> </p>
>>
>>
>>
>> Then the resolved computed value of tts:lineHeight on the paragraph p1 is
>> "14pt". In other words, we could have specified the equivalent with:
>>
>>
>>
>> <p id="p1" tts:fontSize="12pt" tts:lineHeight="14pt">...</p>
>>
>>
>>
>> On the other hand, if this content mapped were selected into two regions,
>> such as:
>>
>>
>>
>> <p tts:fontSize="12pt" tts:lineHeight="normal">
>>
>> <span region="r1" tts:fontSize="10pt">FOO</span>
>>
>> <span region="r1" tts:fontSize="12pt">BAR</span>
>>
>> <span region="r2" tts:fontSize="14pt">BAZ</span>
>>
>> </p>
>>
>>
>>
>> Then the computed line height that applies to p1 in region r1 would be
>> 12pt, but in region r2 would be 14pt.
>>
>>
>>
>>
>>
>> [TTML 8.2.12] continued:
>>
>> Furthermore, it is the intention of this specification that the
>> allocation rectangle of a line be consistent with the
>> per-inline-height-rectangle as defined by [XSL 1.1], § 4.5, i.e., that a
>> CSS-style line box stacking strategy be used.
>>
>>  Here's where things get complex to interpret (particularly when trying
>> to decode the language in XSL-FO). However, before we do that, let's take
>> note of some simplifying factors that hold in TTML than apply to XSL-FO and
>> CSS:
>>
>>
>>
>> In particular, in TTML1 (though perhaps not TTML2 when we introduce
>> images):
>>
>>    - tts:lineHeight only applies to the paragraph element p, and does
>>    not apply to span or br;
>>    - all inline children of p are non-replaceable (text) elements; i.e.,
>>    there are no replaceable elements like <img/> [if some profile introduces
>>    replaceable elements in a superset extension, then this simplifying
>>    assumption may not hold];
>>
>>  In general, in both XSL-FO and CSS, these assumptions don't hold, so
>> the descriptive text in XSL-FO is more complex to interpret.
>>
>>
>>
>> Before I attempt to explain the XSL-FO text, I will summarize the three
>> line stacking strategies defined there:
>>
>>
>>
>> *font-height*
>>
>>
>>
>> Produces constant distance between the baselines of adjacent line areas.
>> The height of a line area's allocation rectangle is the height of the *
>> nominal-requested-line-rectangle*, which is the sum of the altitude and
>> the depth, i.e., font size, of the font that applies to the containing
>> block element (ignoring altitude and depth of the fonts that apply to the
>> line area's child areas).
>>
>>
>>
>> Line areas of a block are stacked (in the block progression dimension) so
>> that the distance between baselines are constant and equal to the computed
>> value of the line height property of the containing block element. This is
>> accomplished by (1) computing the half-leading trait of a block area as
>> half the difference between the computed value of the line-height property
>> and the sum of the computed values of the text-altitude and text-depth
>> properties, then (2) assigning this half-leading to the space-before and
>> space-after traits of each line area generated by the block.
>>
>>
>>
>> Note that half-leading is negative if line-height is less than altitude
>> plus depth (font size), in which case line area rectangles will overlap.
>>
>>
>>
>> *max-height*
>>
>>
>>
>> Produces constant distance between the adjacent edges of consecutive line
>> areas, i.e., between the after edge of line N and the before edge of line
>> N+1. The height of a line area's allocation rectangle is the height of the
>> *maximum-line-rectangle*, which is the greater of (a) the height of the
>> nominal-requested-line-rectangle described above and (b) the sum of the
>> maximum altitude and maximum depth of the *allocation rectangles* of the
>> line area's child inline areas.
>>
>>
>>
>> If no child inline area has an altitude (distance above baseline) greater
>> than the altitude of the containing block's font and no child inline area
>> has a depth (distance below baseline) greater than the depth of the
>> containing block's font, then the result will be identical to the *
>> font-height* strategy.
>>
>>
>>
>> Note that the *allocation rectangle* of an inline area generated by an
>> element comes in two flavors [5]:
>>
>>    - normal-allocation-rectangle
>>    - large-allocation-rectangle
>>
>>  In general, non-replaceable elements, e.g., text, generate normal
>> allocation rectangles, while replaceable elements, e.g., images, generate
>> large-allocation-rectangles. The former "normal" variety *does not*include padding and border when computing its height, while the latter
>> "large" variety *does* include padding and border.
>>
>>
>>
>> [5] http://www.w3.org/TR/2006/REC-xsl11-20061205/#area-geo
>>
>>
>>
>> Note further, and importantly (for what follows), that this strategy does
>> not take into account (a) a different line height property of any
>> non-replaceable child element and (b) the space (margin) before (top) and
>> after (bottom) properties of any replaceable child element.
>>
>>
>>
>> Half-leading computation and usage follows the same rules described above
>> for the font-height strategy, meaning that half-leading may be negative,
>> and thus cause line area rectangle overlap.
>>
>>
>>
>> *line-height*
>>
>>
>>
>> Effectively the same as the max-height strategy, except that (a)
>> half-leading is computed on a per-line basis, (b) the half-leading of
>> non-replaceable child inline elements is applied (rather than ignored), and
>> (c) the margin (space) in the block progression dimension of replaceable
>> child inline elements is applied (rather than ignored).
>>
>>
>>
>> More specifically, the height of a line area's allocation rectangle is
>> the height of the *per-inline-height-rectangle*, which is the greater of
>> (a) the height of the expanded-nominal-requested-line-rectangle (see below)
>> and (b) the sum of the maximum altitude and maximum depth of
>> the expanded-rectangle (see below) of each of the line area's child inline
>> areas.
>>
>>
>>
>> The *expanded-nominal-requested-line-rectangle* is the same as the
>> nominal-requested-line-rectangle described above except that it is *
>> expanded* in the before and after directions by an amount equal to the
>> half leading of the containing block area. [If this half leading is
>> negative, it will be contracted rather than expanded.]
>>
>>
>>
>> The *expanded-rectangle* of an inline area child of a line area is the
>> same as its allocation-rectangle described (under max-height strategy)
>> above except that it is *expanded* in the before and after directions by
>> either (1) an amount equal to the half leading of the inline area, if
>> generated by a non-replaceable element, or (2) amounts equal to the
>> margin-{top,bottom} (or space-{before,after}), respectively, of the inline
>> area, if generated by a replaceable element.
>>
>>
>>
>> Because the half-leading of the containing block is already taken into
>> account by the expanded-nominal-requested-line-rectangle, the space-before
>> and space-after traits of each line area are set to zero.
>>
>>
>>
>> This strategy corresponds to the line stacking strategy adopted by CSS,
>> and is adopted by TTML, Section 9.3.3, step (5), when mapping intermediate
>> synchronic documents to XSL-FO [6].
>>
>>
>>
>> [6]
>> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1.html#semantics-region-layout-step-2
>>
>>
>>
>> As mentioned above, however, TTML1 does not presently apply line-height
>> to inline elements (span or br), and thus the half-leading of each inline
>> element is zero, and does not support a replaceable element type. *Consequently,
>> the line-height strategy, when applied to TTML1, produces equivalent
>> results as produced by the max-height strategy.* That is, each
>> per-inline-height-rectangle is the same height as the equivalent
>> maximum-line-rectangle to which half-leading (of the block) has been added
>> (instead of applying this half-leading to the space-{before,after} of the
>> line area).
>>
>>
>>
>> So, with TTML1, this produces line areas that abut one another in the
>> block progression dimension, but whose height includes half leading both
>> before and after, as contrasted with max-height, where line areas don't
>> abut but rather use space before and after on line areas to represent half
>> leading.
>>
>>
>>
>>
>>
>> [XSL 4.5]
>>
>> The per-inline-height-rectangle for a line-area is the rectangle whose
>> start-edge and end-edge are parallel to and coincident with the start-edge
>> and end-edge of the nominal-requested-line-rectangle, and whose extent
>> in the block-progression-dimension is determined as follows.
>>
>> ….
>>
>> The extent of the per-inline-height-rectangle in the
>> block-progression-direction is then defined to be the minimum required
>> to enclose both the expanded-nominal-requested-line-rectangle and the
>> expanded-rectangles of all the inline-areas stacked within the line-area;
>> this may vary depending on the descendants of the line-area.
>>
>> ….
>>
>> 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.
>>
>> …..
>>
>> 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.
>>
>> ……
>>
>> The nominal-requested-line-rectangle for a line-area is the rectangle
>> whose start-edge is parallel to the start-edge of the content-rectangle of
>> the nearest ancestor reference-area and offset from it by the sum of the
>> start-indent and the start-intrusion-adjustment of the line area, whose
>> end-edge is parallel to the end-edge of the content-rectangle of the
>> nearest ancestor reference-area and offset from it by the sum of the
>> end-indent and the end-intrusion-adjustment of the line area, whose
>> before-edge is separated from the baseline-start-point by the
>> text-altitude of the parent block-area, and whose after-edge is separated
>> from the baseline-start-point by the text-depth of the parent block-area.
>> It has the same block-progression-dimension for each line-area child of a
>> block-area.
>>
>> …
>>
>> [XSL 6.5.2]
>>
>> 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.
>>
>>
>>
>> CONCLUSION: Therefore lineHeight for each line of text in a TTML
>> document is given by: largest fontSize on the line + half leading == 1.5
>> * largest fontSize
>>
>>  First, we must distinguish between the height of a line area and the
>> computed value of the lineHeight property on an element. Here, you use the
>> term "lineHeight", so I'm not sure to which of these you are referring.
>>
>>
>>
>> As I indicated above, the computed value of the 'normal' lineHeight
>> property value is derived from the maximum font size over the entire set of
>> descendants of a paragraph element (in a particular intermediate synchronic
>> document). Or, if the lineHeight property is specified as a length, then
>> that is resolved as usual (without reference to any descendant element's
>> font size).
>>
>>
>>
>> Once the computed lineHeight value is resolved, now you can compute half
>> leading and then derive individual line area rectangle heights according to
>> the line stacking strategy rules.
>>
>>
>>
>> So, if I were to state the correct conclusion, it would read:
>>
>>
>>
>> *CONCLUSION: In TTML1, the height of a line area rectangle generated by
>> a paragraph (<p/>) element is the greater of (a) the computed value of the
>> lineHeight property that applies to the paragraph and (b) the sum of the
>> maximum altitude and maximum depth of each font that applies to the line
>> area's child inline areas.*
>>
>>
>>
>> For those that wish to delve even deeper, I'd suggest reading:
>>
>>
>>
>> [7] https://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2000Nov/0027.html(Member Only)
>>
>> [8] http://meyerweb.com/eric/css/inline-format.html
>>
>>
>>
>> Regarding [7], I'll check with the author to see if he minds me resending
>> his message to this public list.
>>
>>
>>
>> G.
>>
>>
>>
>> --
>>
>> ------------------------------------------------
>>
>> Andreas Tai
>>
>> Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
>>
>> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
>>
>> Floriansmuehlstrasse 60, D-80939 Munich, Germany
>>
>>
>>
>> Phone: +49 89 32399-389 | Fax: +49 89 32399-200
>>
>> http: www.irt.de | Email: tai@irt.de
>>
>> ------------------------------------------------
>>
>>
>>
>> registration court&  managing director:
>>
>> Munich Commercial, RegNo. B 5191
>>
>> Dr. Klaus Illgner-Fehns
>>
>> ------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> ------------------------------------------------
> Andreas Tai
> Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
> Floriansmuehlstrasse 60, D-80939 Munich, Germany
>
> Phone: +49 89 32399-389 | Fax: +49 89 32399-200
> http: www.irt.de | Email: tai@irt.de
> ------------------------------------------------
>
> registration court&  managing director:
> Munich Commercial, RegNo. B 5191
> Dr. Klaus Illgner-Fehns
> ------------------------------------------------
>
>