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

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 09:47:16 UTC