Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider applying ipd or bpd to content images #140

Closed
plehegar opened this issue Nov 4, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@plehegar
Copy link
Member

commented Nov 4, 2015

It's reasonable to apply ipd and bpd to image and have an implied scaling semantic. People are already used to that concept in HTML.

(raised by Glenn Adams on 2015-04-10)
From tracker issue http://www.w3.org/AudioVideo/TT/tracker/issues/387

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented Dec 16, 2016

I cannot see any specification now for what happens if an image is placed in a span that specifies ipd and bpd, and the extent of the image is not equal to that specified size. I agree that it seems reasonable to specify an implied scaling semantic in that case.

@skynavga skynavga modified the milestone: TTML2WR Feb 23, 2017

@skynavga skynavga self-assigned this Apr 20, 2017

@skynavga skynavga removed their assignment May 11, 2017

@skynavga

This comment has been minimized.

Copy link
Collaborator

commented May 17, 2017

@nigelmegitt regarding #140 (comment), this was (originally) about using ipd/bpd on <image> in an inline context, and not about using ipd/bpd on <span>. However, at this point we have already specified the ability to use tts:extent on <image> in both block and inline contexts, so we have already satisfied the original request and can close this issue.

@skynavga skynavga closed this May 17, 2017

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented May 19, 2017

@skynavga I'm still not clear from the current ED what the image presentation semantic is though:

§9.1.5 image includes:

An image element may specify an tts:extent style attribute in order to specify the presentation width or height of the image when intrinsic width or height information is not available or is intended to be overridden. If this attribute is specified on both an image element in an image presentation context and on the image element in an image defining context to which the former refers, then the attribute specified on the former takes precedence over the one specified on the latter.

And §10.2.16 tts:extent says:

If a tts:extent attribute is specified on an image element, then its computed value determines the width and height of the image.

So we see that the width and height of the image are overridden or determined by setting tts:extent and that results in a computed extent value, but we do not define what the presentation behaviour should be when the computed extent does not equal the intrinsic size of the image, for example all of the following appear to be conformant:

  1. scale the image anamorphically to fit the exact dimensions,
  2. scale the image to fit in the largest dimension,
  3. (if larger than the computed extent in either dimension) crop the image to fit,
  4. (if smaller than the computed extent in either dimension) locate the image at some position (which?) within the area that has the computed extent and fill the rest with some background colour (which?),
  5. (if smaller than the computed extent in either dimension) repeat the image to fill the area that has the computed extent.

Possibly there are other options! I think we need to be specific, probably that we mean option 1. Or please point me to the existing text that I've failed to find...

@nigelmegitt nigelmegitt reopened this May 19, 2017

skynavga added a commit that referenced this issue May 21, 2017

Add note regarding anamorphic scaling of image with extent (#140); cl…
…arify image usage in defining context.
@skynavga

This comment has been minimized.

Copy link
Collaborator

commented May 21, 2017

Add note in c14d76a regarding anamorphic scaling.

@skynavga skynavga closed this May 21, 2017

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented May 25, 2017

Why is the anamorphic scaling semantic defined only in a note and not made normative? Probably this is something we should discuss. I was not expecting a non-normative resolution to this issue, so in my view it is not yet closed.

@nigelmegitt nigelmegitt reopened this May 25, 2017

skynavga added a commit that referenced this issue May 25, 2017

@skynavga

This comment has been minimized.

Copy link
Collaborator

commented May 25, 2017

Addressed in afead4c.

@skynavga skynavga closed this May 25, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.