RE: [ttml2] Does tts:backgroundImage affect size of content area?

This condition is an invalid document and thus decoder behavior is undefined.

 Mike

-----Original Message-----
From: Glenn Adams via GitHub [mailto:sysbot+gh@w3.org] 
Sent: Saturday, April 16, 2016 1:47 PM
To: public-tt@w3.org
Subject: [ttml2] Does tts:backgroundImage affect size of content area?

skynavga has just created a new issue for
https://github.com/w3c/ttml2:

== Does tts:backgroundImage affect size of content area? == According to SMTPE ST2052-1:2013 ยง5.5.6:

> The min-height and min-width of the area associated with the image
shall be set to the intrinsic height and width of the image source.

and

> The presented image shall not be scaled and the XSL background-color
 trait shall be visible for any background areas of the ``<div>`` 
outside the image, therefore, authors should ensure that the div will 
be sized to match the given pre-rendering.

The effects of these two requirements are that if an image is larger 
than the nominal minimum content size of the generated area, then that
 minimal content size is to be increased to encompass the intrinsic 
image size as required. While if the nominal minimum content size is 
already larger than the intrinsic image size, the background color of 
the generated area (if not transparent) will be visible outsize the 
image, i.e., the image is not scaled in either dimension to fill the 
nominal minimum content size in such a case.

IMSC1, which makes use of the ``smpte:backgroundImage`` extension, 
does not specify any details about sizing, other than to say that the 
intrinsic image size must correspond to the size of the region into 
which its associated generated area(s) are flowed. As such, one may 
presume that IMSC1 intends the above language from ST2052 to apply 
(Pierre?).

The problem here is that this behavior is at variance with both XSL-FO
 and CSS, where the minimum content size of generated areas associated
 with a background image **is not** increased to the intrinsic image 
size. In other words, in XSL-FO or CSS, if there is no content in the 
element, then no area is generated, or if one is generated, it has 
zero for one or both content area dimensions. On the other hand, if 
there is content in the element, but its nominal formatted size is 
smaller than the intrinsic size of the background image, then some of 
the image will be clipped. I am attaching a test file that 
demonstrates the CSS behavior below.

Now, the problem here in TTML2 is how to handle this discrepancy 
w.r.t. XSL-FO and CSS introduced by SMPTE-TT and apparently adopted by
 IMSC1. One way to handle it would be to require that ``tts:ipd`` and 
``tts:bpd`` be used with TTML2 if one wants such behavior with a 
background image (in a like manner to how one is forced to specify 
width and height properties in XSL-FO or CSS). Or we could add a 
``tts:{ipdMinimum,bpdMinimum}`` pair in TTML2 to specify instead. Or 
we could generalize the values of ``tts:{ipd,bpd}`` to allow 
specifying a (minimum, optimum, maximum) tuple. Or we could allow the 
minimum values of these properties to be specified with a keyword, say
 ``backgroundImageSize``.

In any case, we have an issue here, so I have added an editorial note 
to the section on 
(tts:backgroundImage)[https://rawgit.com/w3c/ttml2/master/spec/ttml2.html#style-attribute-backgroundImage]
 in the TTML2 ED.

Following is the CSS example file:

[test.html.zip](https://github.com/w3c/ttml2/files/222397/test.html.zip)



Please view or discuss this issue at 
https://github.com/w3c/ttml2/issues/157 using your GitHub account

Received on Monday, 18 April 2016 14:47:03 UTC