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

On Thu, Sep 25, 2014 at 9:44 AM, Pierre-Anthony Lemieux <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> 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.
> >
> >
> >
>
>