Re: Clarification needed regarding tts:overflow

> But in a conversation the part highlighted below was mentioned
> and I needed some clarification.

I had the same initial reaction as Andreas. I suspect other have or
will as well, and recommend a clarifying note be added.

Best,

--- Pierre

On Sun, Nov 3, 2013 at 10:27 AM, Andreas Tai <tai@irt.de> wrote:
> 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> 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
>> ------------------------------------------------
>
>
>
>
> --
> ------------------------------------------------
> 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 Tuesday, 5 November 2013 05:27:57 UTC