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

Glenn,

Errata now publish at
http://www.w3.org/2013/09/ttml1-errata.html

There are a couple of issues in your document [1] that need to be fix.


The link checker [2] reports 2 broken links:

----------------------------------
error Lines: 238, 249 
https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1-errata.html
     Status: 200 Script output follows

Some of the links to this resource point to broken URI fragments (such 
as index.html#fragment).
     Broken fragments:

https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1-errata.html#xml-media 
(line 249)

https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1-errata.html#parameter-attribute-profile 
(line 238)
----------------------------------


I have fixed these 2 broken links in the final document [3], with what I 
beleive are the proper URI.

Let me know if it is OK.

Thierry



[1] 
https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1-errata.html

[2] 
http://validator.w3.org/checklink?uri=https%3A%2F%2Fdvcs.w3.org%2Fhg%2Fttml%2Fraw-file%2Fdefault%2Fttml1%2Fspec%2Fttml1-errata.html&hide_type=all&depth=&check=Check

[3] http://www.w3.org/2013/09/ttml1-errata.html

Thierry



On 30/09/2014 17:21, Thierry MICHEL wrote:
> 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 16:44:46 UTC