Re: ISSUE-345: tts:overflow - ambiguous language about region extent [TTML 1.0 (Editorial)]

Hi Glenn et al.,

Referring to [1] and per the TTWG call earlier, below are questions/suggestions:

- does the proposed note replace the existing note under the paragraph
that starts with "If the value of this attribute is visible"?

- the second paragraph of the note, which corrects the normative text
immediately above, should appear first. The first paragraph of the
note, which provides additional details can appear second, or perhaps
after the illustrative example. The idea is to provide the reader with
a crisp statement on the interpretation of the normative text.

Best,

-- Pierre

[1] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1-errata.html#errata-8.2.15-1

On Tue, Sep 16, 2014 at 9:10 PM, Timed Text Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:
> ISSUE-345: tts:overflow - ambiguous language about region extent [TTML 1.0 (Editorial)]
>
> http://www.w3.org/AudioVideo/TT/tracker/issues/345
>
> Raised by: Glenn Adams
> On product: TTML 1.0 (Editorial)
>
> The normative text in TTML1 8.2.15 (tts:overflow) ", and region composition and layout must be performed as if the region's width and height were unconstrained" has been misinterpreted (based on its surface, but not intended meaning) to mean that a region's size is automatically extended to contain overflowed content. Since it is not the intent of this language to override or contradict the existing semantics of the overflow property of XSL 1.1 or CSS2.1, a clarifying note is needed (in errata and eventual incorporation) as follows:
>
> <quote>
> Note:
>
> This attribute has no impact on presentation processing when no overflow condition applies. Furthermore, an overflow condition only applies in either (or both) of two specific contexts: (1) when tts:wrapOption is noWrap and the bounding box of some descendant glyph area overflows (extends outside of) the containing region's nominal content area extent in the inline progression dimension, or (and) (2) when the bounding box of some descendant line area overflows (extends outside of) the containing region's nominal content area extent in the block progression dimension, where the nominal content area extent in the inline and block progression dimensions is determined by the computed values of the tts:extent and tts:padding style properties of the containing region. Furthermore, when an overflow condition applies, it is not intended that the effective extent of the region be modified for the purpose of presentation processing. For example, the area painted with the region's background color is not extended in either dimension to enclose the overflowed content.
>
> Note that, in particular, the normative text in the previous paragraph "region composition and layout must be performed as if the region's width and height were unconstrained" refers to the process of determining the effective extent and origin of descendant line areas produced in either (or both) of the two overflow contexts described here, and is not intended to imply that the region extent is altered for the purpose of determining the region's padding area insets or the extent of its background color. More specifically, the normative language above is not intended to override or contradict the semantics of [XSL 1.1], § 7.21.2, or of [CSS2], § 11.1.1, on which the former is based.
> </quote>
>
> A fix is also needed in TTML2, which is best obtained by simply removing the problem language ", and region composition and layout must be performed as if the region's width and height were unconstrained", this language not being necessary and potentially generating mis-interpretations. In TTML, when it comes to style semantics, one should first determine the XSL-FO (and CSS) semantics, and then determine if the TTML semantics intentionally overrides or modifies these semantics. If the answer is no, then the XSL-FO/CSS semantics apply in whole. This is the criteria in the case of this particular issue: no override or modification of XSL-FO/CSS overflow semantics was intended.
>
>
>

Received on Thursday, 25 September 2014 15:45:30 UTC