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 17:21:43 +0200
Message-ID: <542ACA87.4030705@w3.org>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>, Pierre-Anthony Lemieux <pal@sandflow.com>
CC: Glenn Adams <glenn@skynav.com>, Timed Text Working Group <public-tt@w3.org>
Yes. Will do.

On 30/09/2014 17:16, Nigel Megitt wrote:
> 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:22:15 UTC

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