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

The proposed errata text refers in the 1st paragraph to "1) … the bounding box of some descendant glyph area …" and then "2) … the bounding box of some descendant line area …" (my emphasis).

Aren't they both line areas?

If so I'd suggest simplifying the 1st paragraph as follows (colours relative to the current errata text, sorry for the bright orange highlight colour, but weirdly Outlook won't let me choose the more normal colour for deletions):

--
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 An overflow condition applies when the bounding box of some descendant line area extends outside of the containing region's nominal content area extent in either or both 1) the inline and 2) the block progression dimensions, where the nominal content area extent in both dimensions is determined by the computed values of the tts:extent and tts:padding properties of the containing region. Overflow in the inline progression dimension can occur only if tts:wrapOption is noWrap. 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.
—

Kind regards,

Nigel


From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Thursday, 25 September 2014 18:25
To: Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>>
Cc: Timed Text Working Group <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: Re: ISSUE-345: tts:overflow - ambiguous language about region extent [TTML 1.0 (Editorial)]
Resent-From: <public-tt@w3.org<mailto:public-tt@w3.org>>
Resent-Date: Thursday, 25 September 2014 18:26



On Thu, Sep 25, 2014 at 9:44 AM, Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>> wrote:
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"?

No. The errata says:

Add the following Note immediately after the paragraph starting with "If the value of this attribute is visible...":

It does not say replace or modify the existing note. If it did, then it would use red or green highlighting as noted in:
Conventions

Added text marked thus. Removed text marked thus. Changed text marked thus.



- the second paragraph of the note, which corrects the normative text
immediately above, should appear first.

It elaborates or clarifies as opposed to "corrects".

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.

Thanks for your suggestion about an editorial change to the order of the paragraphs. I find that the current order is sufficient and necessary as the second paragraph refers explicitly to the two contexts of interpretation described in the first paragraph. If I changed the order, then the first paragraph would require a forward reference instead of backward reference. In general, we avoid forward references as it makes understanding more difficult. In conclusion, I decline to make the proposed  change.

If you find there is a factual or grammatical error in the proposed errata, then please let me know.


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<mailto:sysbot%2Btracker@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.
>
>
>