W3C home > Mailing lists > Public > public-tt@w3.org > September 2014

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

From: Thierry MICHEL <tmichel@w3.org>
Date: Tue, 30 Sep 2014 12:24:50 +0200
Message-ID: <542A84F2.7030208@w3.org>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>, Pierre-Anthony Lemieux <pal@sandflow.com>, Glenn Adams <glenn@skynav.com>
CC: Timed Text Working Group <public-tt@w3.org>
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 10:25:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:18 UTC