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

On Fri, Sep 26, 2014 at 5:42 AM, John Birch <John.Birch@screensystems.tv>
wrote:

>  Is there any text that highlights another significant difference between
> the two directions of overflow?
>
> i.e. that overflow in the inline progression dimension does not create
> additional line area descendants, but that overflow in the block
> progression direction *may* create additional line area descendants…
>

Yes. See XSL-FO Section 4 Area Model [1]. Keep in mind that we did not want
to re-invent a layout/formatting model for TTML, and refer to XSL-FO (and
soon CSS) for two possible renderings. Unfortunately, that means you need
to understand those models.

[1] http://www.w3.org/TR/xsl/#area_model


>
>
> best regards,
>
> John
>
>
>
>
> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
> Mobile : +44 7919 558380 | Fax : +44 1473 830078
> John.Birch@screensystems.tv | www.screensystems.tv |
> https://twitter.com/screensystems
>
>
>
> *Visit us at SMPTE Annual Technical Conference, Loews Hollywood Hotel,
> Stand 107, October 21-23 Languages & the Media, Hotel Radission Blu,
> Berlin, November 5-7 *
>
> *P** Before printing, think about the environment*
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* 26 September 2014 12:33
> *To:* Nigel Megitt
> *Cc:* Pierre-Anthony Lemieux; Timed Text Working Group
>
> *Subject:* Re: ISSUE-345: tts:overflow - ambiguous language about region
> extent [TTML 1.0 (Editorial)]
>
>
>
> 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.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.
> >
> >
> >
>
>
>
>
>
>
>
>  This message may contain confidential and/or privileged information. If
> you are not the intended recipient you must not use, copy, disclose or take
> any action based on this message or any information herein. If you have
> received this message in error, please advise the sender immediately by
> reply e-mail and delete this message. Thank you for your cooperation.
> Screen Subtitling Systems Ltd. Registered in England No. 2596832.
> Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich,
> Suffolk, IP6 0EQ
>    ­­
>