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

That’s great , just wanted to make sure that distinction was covered…

J

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<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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:45
To: John Birch
Cc: Nigel Megitt; Pierre-Anthony Lemieux; Timed Text Working Group
Subject: 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<mailto: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<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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<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<mailto:nigel.megitt@bbc.co.uk>> wrote:


From: Glenn Adams <glenn@skynav.com<mailto: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<mailto: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<mailto:glenn@skynav.com>>
Date: Thursday, 25 September 2014 18:25
To: Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>>
Cc: Timed Text Working Group <public-tt@w3.org<mailto: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<mailto: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<mailto: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<mailto:sysbot%2Btracker@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
  ­­