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