W3C home > Mailing lists > Public > public-tt@w3.org > November 2013

Re: Clarification needed regarding tts:overflow

From: Glenn Adams <glenn@skynav.com>
Date: Sun, 3 Nov 2013 01:10:59 -0500
Message-ID: <CACQ=j+dcaEVKPvaY2kY8mygmyQrp1kByRL1nP7mGVoD0TP8Yzw@mail.gmail.com>
To: Andreas Tai <tai@irt.de>
Cc: public-tt <public-tt@w3.org>
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> 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> 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 | Fax: +49 89 32399-200
> http: www.irt.de | Email: tai@irt.de
> ------------------------------------------------
>
> registration court&  managing director:
> Munich Commercial, RegNo. B 5191
> Dr. Klaus Illgner-Fehns
> ------------------------------------------------
>
>
Received on Sunday, 3 November 2013 06:11:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:13 UTC