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

Hi Thierry and Nigel,

I do not object to publishing the errata.

Best,

-- Pierre

On Tue, Sep 30, 2014 at 3:24 AM, Thierry MICHEL <tmichel@w3.org> wrote:
> Nigel, Pierre,
>
> I was also unclear about the resolution.
> Pierre are you ok to publish the errata as is ?
>
> thierry
>
>
> On 30/09/2014 11:46, Nigel Megitt wrote:
>>
>> Pierre,
>>
>> I'm not clear if this represents acceptance by you or not? Are you able to
>> unblock this so Thierry can go ahead and publish, please?
>>
>> Kind regards,
>>
>> Nigel
>>
>>
>> On 27/09/2014 04:04, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:
>>
>>> 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.h
>>>>>>> tml#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 Tuesday, 30 September 2014 15:15:20 UTC