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

No objection to Nigel's suggestions. I remain of the opinion that the
portion of the note clarifying the "must" statements should be first.

-- Pierre

On Fri, Sep 26, 2014 at 4:33 AM, Glenn Adams <glenn@skynav.com> wrote:
> 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.
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>
>

Received on Saturday, 27 September 2014 03:04:54 UTC