Add parameter signaling the editorial area of a document instance

[palemieux]

As requested at https://lists.w3.org/Archives/Member/member-tt/2016Sep/0001.html and per https://lists.w3.org/Archives/Public/public-tt/2016Jun/0003.html, add a parameter that allows an author to signal the rectangular area that fully contains all of the referenced regions within the content.

See also:

• draft at https://www.w3.org/TR/ttml2/#parameter-attribute-safeCropArea
• SMPTE liaison at https://lists.w3.org/Archives/Member/member-tt/2017Jan/0003.html
• further DVB communication at https://lists.w3.org/Archives/Member/member-tt/2017Jan/0001.html

[skynavga]

I believe there are two problems here:

1. the original proposal does not define the region of question as "an editorial area";

2. the original proposal does not define the region of question as fully enclosing all referenced regions;

[palemieux]

the original proposal does not define the region of question as fully enclosing all referenced regions;

From the BBC document: typically the Safe Crop Area would be an area that fully contains
all of the referenced regions within the content

the original proposal does not define the region of question as "an editorial area";

From the same BBC input: one alternative that has been proposed is "Subtitle Editorial Area"

[skynavga]

On Thu, Jan 5, 2017 at 11:10 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: the original proposal does not define the region of question as fully enclosing all referenced regions; From the BBC document <https://lists.w3.org/Archives/Public/public-tt/2016Jun/0003.html>: *typically the Safe Crop Area would be an area that fully contains all of the referenced regions within the content*

"typically" does not mean that is the definition, it means one possible example; an author controls what they want in the area, and that may or may not enclose all regions or all parts of all regions;

the original proposal does not define the region of question as "an editorial area"; From the same BBC input: *one alternative that has been proposed is "Subtitle Editorial Area"*

"safe crop area" is an industry known term; there is no need to rename it, as it will only cause confusion in reader's minds; i.e., their first question will be "how is this related to safe crop area?" the answer of which "this is the safe crop area"; so a new name is unnecessary and produces confusion

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb4raoE7LM0d_5FK7YFC9Tt6MCI4dks5rPdrHgaJpZM4LZLo1> .

[palemieux]

"typically" does not mean that is the definition, it means one possible
example; an author controls what they want in the area, and that may or may
not enclose all regions or all parts of all regions;

See the PR for the exact proposed text.

"safe crop area" is an industry known term; there is no need to rename it,
as it will only cause confusion in reader's minds; i.e., their first
question will be "how is this related to safe crop area?" the answer of
which "this is the safe crop area"; so a new name is unnecessary and
produces confusion

See the SMPTE liaison

[skynavga]

One more comment, the name of this property should be changed to ittp:safeCropArea for consistency with TTML2. It serves no purpose to have two distinct names for what is effectively the same semantics.

…

On Mon, Jan 2, 2017 at 12:44 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: As requested at https://lists.w3.org/Archives/ Member/member-tt/2016Sep/0001.html and per https://lists.w3.org/Archives/ Public/public-tt/2016Jun/0003.html, add a parameter that allows an author to signal the rectangular *area that fully contains all of the referenced regions within the content.* See also draft at https://www.w3.org/TR/ttml2/#parameter-attribute- safeCropArea — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#191>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb2383By0uI_jXlnsgQvInsuwjU7gks5rOVO0gaJpZM4LZLo1> .

[mikedo]

Although I agree that the name should be the same throughout TTML profiles, “safe..Area” is a misnomer of the proposed semantics, and it is conflicting and confusing with the same term as used by the television industry for ~50 years as explained by SMPTE’s liaison. Further, “crop” implies some processor action, which is additionally misleading. Use of this information by processors may or may not involve cropping. We must pick some other name. Personally I prefer to retain the analogy with video AFD which defines the “active format” or where pixels are actually defined in the coded video frame, which still seems like the analogous thing to me. So how about “activeFormat” or “activeArea”? Mike

[palemieux]

So how about “activeFormat” or “activeArea”?

IMF (SMPTE ST 2067-2) uses Active Area, so +1

[skynavga]

On Fri, Jan 6, 2017 at 8:03 AM, Michael A Dolan <notifications@github.com> wrote:

Although I agree that the name should be the same throughout TTML profiles, “safe..Area” is a misnomer of the proposed semantics, and it is conflicting and confusing with the same term as used by the television industry for ~50 years as explained by SMPTE’s liaison. Further, “crop” implies some processor action, which is additionally misleading. Use of this information by processors may or may not involve cropping.

How about one of: - safeArea - safeTitleArea See [1] for usage. [1] https://en.wikipedia.org/wiki/Safe_area_(television)

We must pick some other name. Personally I prefer to retain the analogy with video AFD which defines the “active format” or where pixels are actually defined in the coded video frame, which still seems like the analogous thing to me. So how about “activeFormat” or “activeArea”?

This may be potentially confused with *action-safe area*, also see [1].

…

Mike --------------------------- Michael A DOLAN TBT, Inc; PO Box 190 Del Mar, CA 92014 +1-858-882-7497 <(858)%20882-7497> From: Glenn Adams ***@***.*** Sent: Thursday, January 5, 2017 10:52 PM To: w3c/imsc ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [w3c/imsc] Add parameter signaling the editorial area of a document instance (#191) One more comment, the name of this property should be changed to ittp:safeCropArea for consistency with TTML2. It serves no purpose to have two distinct names for what is effectively the same semantics. On Mon, Jan 2, 2017 at 12:44 PM, Pierre-Anthony Lemieux < ***@***.******@***.***>> wrote: > As requested at https://lists.w3.org/Archives/ > Member/member-tt/2016Sep/0001.html and per https://lists.w3.org/Archives/ > Public/public-tt/2016Jun/0003.html, add a parameter that allows an author > to signal the rectangular *area that fully contains all of the referenced > regions within the content.* > > See also draft at https://www.w3.org/TR/ttml2/#parameter-attribute- > safeCropArea > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#191>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAXCb2383By0uI_ jXlnsgQvInsuwjU7gks5rOVO0gaJpZM4LZLo1> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://github.com/w3c/ imsc/issues/191#issuecomment-270843740>, or mute the thread< https://github.com/notifications/unsubscribe-auth/AEUs9O3HRg2PHK_ uei0vMzXq1yJGy4m0ks5rPeSggaJpZM4LZLo1>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCbxjjV5GJmhhfLDRp4Ykiux_hmcq4ks5rPlewgaJpZM4LZLo1> .

[mikedo]

Regarding the proposal: How about one of: - safeArea - safeTitleArea Aside from the fact that this naming is at complete odds with the liaison input from SMPTE, I believe it is incorrect to associate what BBC has asked for with TV Safe Area. As I understand the BBC request, they have asked for a document parameter that provides a bounding rectangle on the actual content in the document. It is analogous to TV AFD, not TV Safe Area. TV Safe Area is a constant subset area of the coded frame (that is not signaled in any way) where TV displays are encouraged to not overscan more than that amount, thus ensuring the content within that area is visible on all models of TV displays. Authors are therefore encouraged to not author outside that “safe” authoring area. There is no concept of signaling or otherwise identifying what area that was actually used. In contrast, and much more analogous to the BBC request, see AFD at: https://en.wikipedia.org/wiki/Active_Format_Description Mike

[andreastai]

I agree with @mikedo that including a processor action as "crop" in the name is misleading. The name should represent information about authorial intention. "subtitleEditorialArea" or "activeArea" or another term that does not conflict with terms in other specifications would work for me.

[skynavga]

I still think crop has semantic significance in that it says that content outside the area *may* be cropped.

…

On Tue, Jan 10, 2017 at 11:45 AM, Andreas Tai ***@***.***> wrote: I agree with @mikedo <https://github.com/mikedo> that including a processor action as "crop" in the name is misleading. The name should represent information about authorial intention. "subtitleEditorialArea" or "activeArea" or another term that does not conflict with terms in other specifications would work for me.

[mikedo]

It may. It may not. It may be scaled. It may be moved….

…

I still think crop has semantic significance in that it says that content outside the area *may* be cropped.

[nigelmegitt]

The point is that of all the options the contents of the area defined shall not be cropped, so it does have semantic significance.

[mikedo]

That’s rather constraining and news to me. So, will you reverse the polarity of the Boolean to be “notCropped”? From: Nigel Megitt [mailto:notifications@github.com] Sent: Wednesday, January 11, 2017 9:13 AM To: w3c/imsc <imsc@noreply.github.com> Cc: Michael A Dolan <md.1@newtbt.com>; Mention <mention@noreply.github.com> Subject: Re: [w3c/imsc] Add parameter signaling the editorial area of a document instance (#191) The point is that of all the options the contents of the area defined shall not be cropped, so it does have semantic significance. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#191 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEUs9OneWWi0-nApkqpWID2Ny6uO_TQ6ks5rRQ2qgaJpZM4LZLo1>.

[nigelmegitt]

@mikedo I think we have our wires crossed - the safeCropArea was always the area within which content should not be cropped.

[mikedo]

Not crossed wires exactly.

I still maintain that a useful feature is metadata for input to a (transformation) processor about a rectangular area bounding the essential content. Such a processor may make use of this metadata in any way it wishes. One way is to ensure it is not cropped by a processor. There are many other ways.

I believe that it is over-constraining of an otherwise very useful feature to either require or forbid any specific processor operation.

If an application environment (e.g. BBC network) wishes to require or forbid certain processor behaviors, that’s fine.

I understand that this more general view may not be what BBC first intended. But in the last few posts, others have used all of "shall", "should" and "may" to describe the intended behavior, so I am also rather unclear on the intent.

[skynavga]

On Wed, Jan 11, 2017 at 11:23 AM, Michael A Dolan ***@***.***> wrote: Not crossed wires exactly. I still maintain that a useful feature is metadata for input to a (transformation) processor about a rectangular area bounding the essential content. Such a processor may make use of this metadata in any way it wishes. One way is to ensure it is not cropped by a processor. There are many other ways. I believe that it is over-constraining of an otherwise very useful feature to either require or forbid any specific processor operation.

I disagree that it is over-constraining. First, support for the feature #safeCropArea is optional to start with (except in the ttml2-full profile). So, assuming for a moment that the profile you are using makes it optional, then you don't have to implement the cropping semantics (at which point the presence of the style parameter in the document is effectively just metadata). If, on the other hand, you do support the feature, then you must not crop inside the area. I don't see any problem requiring implementations that claim support for the feature must not crop (at least as far as the document processing context is concerned). Of course, whatever system lives outside the document processing context may crop without knowledge by the TTML presentation engine.

If an application environment (e.g. BBC network) wishes to require or forbid certain processor behaviors, that’s fine.

Defining the semantics of the style property to mandate non-cropping if the property is supported does not mandate that a processor support the style property.

…

I understand that this more general view may not be what BBC first intended. But in the last few posts, others have used all of "shall", "should" and "may" to describe the intended behavior, so I am also rather unclear on the intent. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb8vHqWLA0s1C0ogms9PSbuQ_qk9Wks5rRR4cgaJpZM4LZLo1> .