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

ok, implemented your suggested changes in [1]; if accepted by Pierre, i'd
like to have Thierry go ahead on publishing

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

On Fri, Sep 26, 2014 at 5:23 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

>
>
>   From: Glenn Adams <glenn@skynav.com> Date: Friday, 26 September 2014
> 13:14
>
>   On Fri, Sep 26, 2014 at 4:52 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
>>  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?
>>
>
>  Nope. Glyph areas are descendents of line areas. Line areas are
> descendants of block areas. However, I suppose we could refer to the line
> area descendant overflowing the block area just as well as saying that the
> glyph area descendant of the line area of the block area overflows the
> block area.
>
>
>  Yes, I meant that we could use the same term for both without
> significant loss of meaning.
>
>    My intent in the example was to separate the two contexts of overflow
> in the inline progression dimension and the block progression dimension. In
> the first case, it is the additional glyph area(s) that is (area) placed in
> the line area the causes the line area's IPD to overflow the content area
> of the block area. In the second case, a line area overflows the block area
> in the block progression dimension, either in part or in entirety.
>
> That being said, I don't mind deleting the orange text and adding the
> green text if you think it is clearer.
>
>
>  Well I think it is clearer, otherwise I wouldn't have proposed it! Also
> it's shorter, which is a nice to have, all other things being equal, avoids
> repetition of "Furthermore" and separates out the wrapOption point from the
> general overflow point. Other views welcome, as always.
>
>
>
>>
>>  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>
>> Date: Thursday, 25 September 2014 18:25
>> To: Pierre-Anthony Lemieux <pal@sandflow.com>
>> Cc: Timed Text Working Group <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>
>> Resent-Date: Thursday, 25 September 2014 18:26
>>
>>
>>
>> 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.
>>> >
>>> >
>>> >
>>>
>>>
>>
>