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

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.

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.


>
>  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.html#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.
>> >
>> >
>> >
>>
>>
>