RE: Clarification needed regarding tts:overflow

On a related topic I have recently been revisiting TTML 1.0 SE.
With regards to lineheight the following algorithm is described:

If a computed value of the property associated with this attribute is not supported, then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between the computed line height and the supported line height is minimized. If there are multiple closest supported values equally distant from the computed value, then the value most distant from 0, i.e., the largest line height, is used.

Whilst I understand and applaud the effort to explicitly state expected behaviour I am concerned that choosing a larger lineHeight than the computed value will in some cases lead to overflow.
Clearly, as discussion shows, in certain contexts (e.g. especially in subtitling), overflow is very undesirable…. In fact IMHO it is difficult to conceive of any situation where an author would prefer the clipping or loss of their text! Or prefer the wrapping of their text, over the presentation of their text in a smaller font but with their authored line presentation preserved ( Note: I’m assuming this cautious author has used separate p elements or br elements to force line breaks).

I can imagine that some justifications for not ALWAYS reducing the font size might be that this impacts readability… but research shows that appropriate phrasing (i.e. line layout) and missing words have a far greater impact upon comprehension!

I can hope that the addition of a ‘shrink to fit’ modality to TTML will resolve my concerns.

Best regards,
John

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 270 | 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
CCW, 13 – 14th November, Stand 1343, Javits Convention Center, New York

P Before printing, think about the environment

From: Andreas Tai [mailto:tai@irt.de]
Sent: 03 November 2013 18:27
To: Glenn Adams
Cc: public-tt
Subject: Re: Clarification needed regarding tts:overflow

Apalogies if I did not made my intention clear enough. It was to prove that my interpretation is not correct and that the use of the feature is as defined in XSL:FO and CSS.

My original interpretation of tts:overflow was always that it has the same semantics as in CSS. But in a conversation the part highlighted below was mentioned and I needed some clarification.

In general I see it as a huge benefit that the layout and formatting of TTML is nearly fully compatible with CSS. This allows a smooth integration in web technologies like HTML 5.

Thanks and best regards,

Andreas

Am 03.11.2013 07:10, schrieb Glenn Adams:
Basically, TTML is doing precisely what XSL-FO and CSS both do here, as defined by the preliminary material in [1]. If you find yourself interpreting TTML style properties in a way that is distinct from CSS semantics, then you should question your interpretation first. We never intentionally diverge except in noted extensions, particularly the use of 'c' metric and the potential use of an anamorphic font size.

[1] http://www.w3.org/TR/CSS2/visufx.html#overflow-clipping


On Sat, Nov 2, 2013 at 12:00 PM, Andreas Tai <tai@irt.de<mailto:tai@irt.de>> wrote:
Thanks Glenn for the clarification!





>From the TTML Spec:

"If the value of this attribute is visible [...] region composition and layout must be performed as if the region's width and height were unconstrained" [1]

>From my reading content that overflows the region extents the "box" of the region.

No. It merely goes outside of that box (and is not clipped by it).

That is different what is shown in the first example of tts:overflow where the background color is only applied to the contrained region extent. Only the text content is rendered outside of the regions box.

The size of the box should not be changed for the purpose of drawing its background.

OK. Seems that I misunderstood it. But from the conversation I had with others I am not the only one. From my view the text marked in red (and '*') leads to this misreading. From my view it would be better to omit it (but possibly it is to late for a change).

"If the value of this attribute is visible, then content should not be clipped outside of the affected region*, and region composition and layout must be performed as if the region's width and height were unconstrained, but with a well-defined origin*. "


- Andreas


Am 01.11.2013 18:56, schrieb Glenn Adams:

On Fri, Nov 1, 2013 at 10:30 AM, Andreas Tai <tai@irt.de<mailto:tai@irt.de>> wrote:
I need some clarification regarding the tts:overflow [1] attribute in TTML 1.0 (2nd edition).

1) Is this attribute only an indicator how presentation processors should handle content that overflows a region?

In the description of the desired presentation behaviour for "visible" and "hidden" the key word "should" and not "must" is used.
(This seems to reflect the usage of overflow in XSL 1.1 and CSS)

Yes. I suspect we used "should not be clipped" because other semantics outside the scope of interpreting this property may cause clipping.


2) Does tts:overflow "hidden" create a "dynamic sized region" where width and height adopts to the size of the content?

No. It simply behaves as if the region into which this content is selected is unconstrained in width (or height) in the inline progression dimension.


>From the TTML Spec:

"If the value of this attribute is visible [...] region composition and layout must be performed as if the region's width and height were unconstrained" [1]

>From my reading content that overflows the region extents the "box" of the region.

No. It merely goes outside of that box (and is not clipped by it).

That is different what is shown in the first example of tts:overflow where the background color is only applied to the contrained region extent. Only the text content is rendered outside of the regions box.

The size of the box should not be changed for the purpose of drawing its background.


Furthermore I believe that if the constrain is meant in that way it is not compatible with CSS.

I'm not sure what you mean here. Could you be more precise, and provide an example (in both TTML and HTML/CSS)?


- Andreas

[1] http://www.w3.org/TR/ttaf1-dfxp/#style-attribute-overflow





--

------------------------------------------------

Andreas Tai

Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH

R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR

Floriansmuehlstrasse 60, D-80939 Munich, Germany



Phone: +49 89 32399-389<tel:%2B49%2089%2032399-389> | Fax: +49 89 32399-200<tel:%2B49%2089%2032399-200>

http: www.irt.de<http://www.irt.de> | Email: tai@irt.de<mailto:tai@irt.de>

------------------------------------------------



registration court&  managing director:

Munich Commercial, RegNo. B 5191

Dr. Klaus Illgner-Fehns

------------------------------------------------





--

------------------------------------------------

Andreas Tai

Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH

R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR

Floriansmuehlstrasse 60, D-80939 Munich, Germany



Phone: +49 89 32399-389 | Fax: +49 89 32399-200

http: www.irt.de<http://www.irt.de> | Email: tai@irt.de<mailto:tai@irt.de>

------------------------------------------------



registration court&  managing director:

Munich Commercial, RegNo. B 5191

Dr. Klaus Illgner-Fehns

------------------------------------------------

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