- From: Andreas Tai <tai@irt.de>
- Date: Wed, 28 Aug 2013 21:24:41 +0200
- To: Glenn Adams <glenn@skynav.com>
- CC: Michael Dolan <mdolan@newtbt.com>, TTWG <public-tt@w3.org>
- Message-ID: <521E4E79.4050608@irt.de>
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
> <mailto: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 <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 <mailto:glenn@skynav.com>> wrote:
>
> On Fri, Aug 23, 2013 at 10:44 AM, Glenn Adams
> <glenn@skynav.com <mailto:glenn@skynav.com>> wrote:
>
> On Fri, Aug 23, 2013 at 8:01 AM, Andreas Tai <tai@irt.de
> <mailto: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
>
>
>
> -------- Original-Nachricht --------
>
> *Betreff: *
>
>
>
> Re: lineHeight
>
> *Weitersenden-Datum: *
>
>
>
> Fri, 23 Aug 2013 02:55:03 +0000
>
> *Weitersenden-Von: *
>
>
>
> public-tt@w3.org <mailto:public-tt@w3.org>
>
> *Datum: *
>
>
>
> Thu, 22 Aug 2013 20:54:09 -0600
>
> *Von: *
>
>
>
> Glenn Adams <glenn@skynav.com> <mailto:glenn@skynav.com>
>
> *An: *
>
>
>
> Michael Dolan <mdolan@newtbt.com>
> <mailto:mdolan@newtbt.com>
>
> *Kopie (CC): *
>
>
>
> TTWG <public-tt@w3.org> <mailto: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 <mailto: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 size that 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 andend-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 <tel:%2B49%2089%2032399-389> | Fax:+49 89 32399-200 <tel:%2B49%2089%2032399-200>
>
> http:www.irt.de <http://www.irt.de/> | Email:tai@irt.de <mailto: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
------------------------------------------------
Received on Wednesday, 28 August 2013 19:27:12 UTC