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

Hi Pierre,

Thank you. 

Thierry, please could you go ahead and publish it as agreed previously?

Kind regards,

Nigel


On 30/09/2014 16:14, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:

>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.h

>>>>>tml
>>>>> #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-errat

>>>>>>>>a.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:17:13 UTC