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

I'm afraid I'm still not following you. My comment is not related to
validity, but the semantics of background image impact on sizing the
content element that refers to it.

SMPTE-TT says that the minimum size of the area generated by the content
element is expanded to fit the size of the background image. This is not
the behavior in CSS or XSL-FO, so it presents an issue for how to deal with
background image in TTML2 and how to translate SMPTE-TT or IMSC1 to TTML2.

My current thinking is that tts:backgroundImage in TTML2 will not have the
behavior of SMPTE-TT or IMSC1, i.e., it will follow the XSL-FO and CSS
behavior. So if background image is used in TTML2, the author will need to
ensure the size of the generated area is sufficiently large, e.g., by
including sufficient content or by using tts:ipd or tts:bpd.

For the purpose of translating SMPTE-TT or IMSC1 to TTML2, a couple options
exist:

   - translate to <image> element rather than tts:backgroundCheck
   - or use tts:backgroundCheck but also specify tts:{ipd,bpd}

I don't see any issue here with respect to validity.

On Mon, Apr 18, 2016 at 11:59 AM, Michael Dolan <mdolan@newtbt.com> wrote:

> The IMSC1 instance document alone can be valid IMSC1.  But in the context
> of it with the collection of (e.g. PNG) image file properties, the
> “package” is not valid.  Just because we don’t have a formalization of the
> “package” doesn’t mean that a decoder should adopt some compensation
> behavior when faced with such a “package”.
>
>
>
>                 Mike
>
>
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, April 18, 2016 9:26 AM
> *To:* Michael Dolan <mdolan@newtbt.com>
> *Cc:* TTWG <public-tt@w3.org>
> *Subject:* Re: [ttml2] Does tts:backgroundImage affect size of content
> area?
>
>
>
> Could you please explain? What is invalid?
>
>
>
> On Mon, Apr 18, 2016 at 8:46 AM, Michael Dolan <mdolan@newtbt.com> wrote:
>
> 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
>
>
>