Add ttp:safeCropArea #184
Add ttp:safeCropArea #184
Conversation
Fix #173 by adding `ttp:safeCropArea` parameter attribute and processing semantics as per BBC contribution at https://github.com/w3c/ttml2/files/397449/Subtitle.Safe.Crop.Area.BBC.su bmission.2016-06-09.pdf
Enclose content in note elements in a p.
| <def> | ||
| <p>The rectangular portion of the <loc href="#terms-root-container-region">root container region</loc> | ||
| identified as being unsuitable for cropping by the <loc href="#terms-presentation-processor">presentation processor</loc>. | ||
| </p> |
There was a problem hiding this comment.
This definition presumes of the outcome: cropping or not cropping. Based on the description, wouldn't a more accurate term and definition be as follows?
Active Area: rectangular area intended to remain visible to the viewer, at the sole discretion of the author
There was a problem hiding this comment.
Yes, okay, I see your point. I'm not sure about "at the sole discretion of the author" though - it seems a bit legalistic and presumes the presence of (and definition of) an author, which is not a defined term.
There was a problem hiding this comment.
I am not wedded to "at the sole discretion of the author". It is intended to emphasize it is an authorial decision, and the resulting "active area" can include a lot of blank space or not include all timed text content.
There was a problem hiding this comment.
Okay, one more tweak then.
Active Area: rectangular area whose presented contents are intended to remain visible to the viewer.
The purpose of this change is to allow for the possibility of methods other than simple scaling and translation of the rendered graphics plane to be employed to achieve the desired outcome.
| @@ -1531,6 +1539,24 @@ specification identifies three such targets: | |||
| </p> | |||
| </def> | |||
| </gitem> | |||
| <gitem id="terms-visible-rendering-region"> | |||
| <label>[visible rendering region]</label> | |||
| <def> | |||
There was a problem hiding this comment.
Why is this definition necessary? Couldn't the recommendation simply be as follows?
The presentation processor should ensure that the content within the "active area" remains visible to the viewer
There was a problem hiding this comment.
The definition is there to ensure that there's a specific concept to relate to in units.
The "recommendation" is a requirement though, not a recommendation.
There was a problem hiding this comment.
Why are units relevant here?
There was a problem hiding this comment.
Sorry, I didn't mean "units" like this, I meant a numerically measurable thing - you're right, units do not need to be mentioned, since they are an internal detail to implementations.
| @@ -4867,6 +4896,53 @@ If specified, then both numerator and demoninator must be non-zero.</p> | |||
| <p>A <att>ttp:pixelAspectRatio</att> attribute is considered to be significant only | |||
| when specified on the <el>tt</el> element.</p> | |||
| </div3> | |||
| <div3 id="parameter-attribute-safeCropArea"> | |||
| <head>ttp:safeCropArea</head> | |||
| <p>The <att>ttp:safeCropArea</att> attribute indicates the area that a presentation processor should display without cropping.</p> | |||
There was a problem hiding this comment.
Reference the definition instead:
the ttp:activeArea signals the Active Area.
There was a problem hiding this comment.
Okay, but I'd put both in, e.g.
| The ttp:safeCropArea attribute indicates the Active Area, being the area that a presentation processor should display without cropping.
There was a problem hiding this comment.
(otherwise it is very hard to fathom what it means)
There was a problem hiding this comment.
| The ttp:safeCropArea attribute indicates the Active Area, being the area that a presentation processor should display without cropping.
I do not think this is right, since it presumes of the outcome, i.e. cropping. Moreover since "active area" is already defined above, there is no need to repeat the definition here, whatever it is.
There was a problem hiding this comment.
Okay, I'll think about how I can phrase this better. Thanks.
| @@ -15438,6 +15514,91 @@ href="http://www.unicode.org/reports/tr14/#Algorithm">Line | |||
| Breaking Algorithm</loc> <bibref ref="uax14"/> apply when performing | |||
| line layout on the content of the <loc href="#terms-document-instance">document instance</loc>.</p> | |||
| </div3> <!-- semantics-line-layout --> | |||
| <div3 id="semantics-safe-crop-area-layout"> | |||
| <head>Safe crop area presentation</head> | |||
| <p>Presentation processors that support safe crop area semantics shall display the TTML | |||
There was a problem hiding this comment.
The "shall" needs to be a "should" here since the author cannot control all the possible ways that a display will crop the content. IMHO this is no different that a display cropping 4:3 content to fill a 16:9 display: it should ideally not be done, but if it is done, it is the responsibility of the display and user.
There was a problem hiding this comment.
Sorry, it has to be a "shall" in TTML2 otherwise the semantic has no useful meaning or purpose. If you want to profile it out then that's a profile issue. For example an IMSC.next could make support of the feature designator optional, with a recommendation.
There was a problem hiding this comment.
I really think "shall" is inappropriate since it requires processor behavior while not specifying precisely the outcome, i.e. what "best endeavours" mean?
There was a problem hiding this comment.
Well what I'm trying to do with this text is, exactly as you say, that we specify the outcome without describing the processor behaviour. I'm not clear what needs to change if I have not achieved that - suggestions welcome.
There was a problem hiding this comment.
I'm not clear what needs to change if I have not achieved that - suggestions welcome.
Use "should" instead of "shall".
| content that falls within the <loc href="terms-safe-crop-area">safe crop area</loc>. | ||
| Presentation Processors should use best endeavours to maintain text size and positional | ||
| alignment of TTML content within the safe crop area relative to the related media object.</p> | ||
| <p>As a minimum, if the safe crop area extends outside the |
There was a problem hiding this comment.
Confirm that this processing is applied after the root container is mapped to the Related Video Object such that the aspect ratio signaled by the author is preserved.
There was a problem hiding this comment.
That's an implementation issue - I'm deliberately not saying that following conversations with manufacturers who think that in this kind of scenario they can do client side processing to display all of the content in all the right places without necessarily doing a simple scaling of the rendering plane. This can include pre-processing of the TTML content.
In general though this has no effect on aspect ratio signalling, regardless of when the processing is applied.
|
By the way, I meant to say thank you @palemieux for taking the time to review this and for your comments, regardless of whether or not I agree with them at first sight! |
|
Closing. Please direct new comments or follow-on remarks to #197. |
|
Reopening - comments can still go on #197 however the issue can be closed when a pull request for it is merged. Adding a "pr open" label to indicate the status. |
|
Oops apologies I thought this was the issue not the pull. |
Fix #173 by adding
ttp:safeCropAreaparameter attribute andprocessing semantics as per BBC contribution at
https://github.com/w3c/ttml2/files/397449/Subtitle.Safe.Crop.Area.BBC.su
bmission.2016-06-09.pdf