- From: Thierry MICHEL <tmichel@w3.org>
- Date: Tue, 30 Sep 2014 12:24:50 +0200
- 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