Make inline region semantics set values on current region

[nigelmegitt]

The current semantic when inline style attributes applicable to regions are used in content elements is to create a new implied inline region.

Options

1. Keep existing semantic where new anonymous regions are created.
2. Modify the semantic such that when region style attributes are encountered on content elements they are used to modify the current region for that content element while the element is active.

Option 2 would be syntactic shorthand for a <set> element on a region that modifies the region's tts:origin, tts:extent or tts:position.

History

I raised this discussion with the thread beginning at https://lists.w3.org/Archives/Public/public-tt/2015Oct/0068.html however it was not concluded.

This issue satisfies tracker action 472.

[skynavga]

I think we can't simply choose one approach only. Existing extension implementations effectively use an anonymous region, not current region. However, I see the utility of having this affect the latter also. So we probably need to support both approaches, and use a new ttp attribute to specify which approach the author wishes to use. For example:

ttp:impliedRegionMethod
  : current
  | new

Where current effectively means apply an anonymous set animation to the current region, and new means create a new anonymous region.

I think new should be the default.

[nigelmegitt]

Okay, that seems reasonable.

[nigelmegitt]

During the discussion in today's meeting it occurred to me that we need to define a precedence if a region-only style attribute is applied to a content element as well as a region attribute, for example:

<region tts:extent="80% 10% xml:id="r1" ...>
...
<div tts:extent="60% 20%" region="r1">

This applies regardless of whether the 'new region' or 'modified region' method is used.

[skynavga]

On Thu, Aug 18, 2016 at 9:21 AM, Nigel Megitt notifications@github.com
wrote:

During the discussion in today's meeting it occurred to me that we need to
define a precedence if a region-only style attribute is applied to a
content element as well as a region attribute, for example:

<region tts:extent="80% 10% xml:id="r1" ...>...

This applies regardless of whether the 'new region' or 'modified region'
method is used.

This would be semantically ill-formed if the 'new' method is used. However,
it would be well-formed for the 'current' method.

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

[nigelmegitt]

That may be the case, however there is no syntactic prohibition on this with either method currently, and the correct processor behaviour is not currently defined for this example even with the 'new' method. Perhaps §11.2.1 region (attribute) would be the appropriate place to put any additional constraints.

Thinking also about w3c/ttml1#194 we could define a similar template mechanism for regions by including a semantic that says that if we create an inline region Rinline for a content element that already had an applicable (non-default) region Rprevious, then Rinline could usefully be initialised with style attributes from Rprevious, rather than from initial. This would allow for region style inheritance without the current behaviour of pruning content selected into a region when another region was already selected. This feels related to the 'current' method...

[skynavga]

On Thu, Aug 18, 2016 at 10:08 AM, Nigel Megitt notifications@github.com
wrote:

That may be the case, however there is no syntactic prohibition on this
with either method currently, and the correct processor behaviour is not
currently defined for this example even with the 'new' method. Perhaps
§11.2.1 region (attribute) would be the appropriate place to put any
additional constraints.

Yes, this is needed. I looked for it and couldn't find a constraint, though
I had some recollection of one.

Thinking also about #ttml1/194 we could define a similar template
mechanism for regions by including a semantic that says that if we create
an inline region Rinline for a content element that already had an
applicable (non-default) region Rprevious, then Rinline could usefully be
initialised with style attributes from Rprevious, rather than from initial.
This would allow for region style inheritance without the current behaviour
of pruning content selected into a region when another region was already
selected. This feels related to the 'current' method...

Hmm. Sounds complicated to implement.

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

[palemieux]

Below is a sample I have seen in the wild:

<style xml:id="basic" tts:color="white" tts:fontFamily="monospace" tts:lineHeight="8%" tts:fontSize="8%" tts:fontWeight="normal"/>
...
<region xml:id="pop1" tts:backgroundColor="transparent"/>
...
<p begin="00:01:01:13" end="00:01:04:16" region="pop1" style="basic" tts:origin="17% 79%">
 <span tts:backgroundColor="black" tts:color="white" tts:fontStyle="normal" tts:fontWeight="normal" tts:textDecoration="noUnderline">I found this cat</span>
</p>

I would think the intent here is to merely apply tts:origin="17% 79%" to the pop1 region. Does the challenge lie in dealing with the possibility that multiple content elements apply tts:origin simultaneously to the same region?

[skynavga]

On Tue, Aug 23, 2016 at 2:48 PM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

Below is a sample I have seen in the wild:

<style xml:id="basic" tts:color="white" tts:fontFamily="monospace" tts:lineHeight="8%" tts:fontSize="8%" tts:fontWeight="normal"/> ... ...

I found this cat

I would think the intent here is to merely apply tts:origin="17% 79%" to the pop1 region. Yes, I can see that by explicitly specifying @region _and_ tts:origin then it may lead to that conclusion. What if @region weren't specified here, but specified on div or body instead? Does the challenge lie in dealing with the possibility that multiple content elements apply tts:origin simultaneously to the same region? The challenge is not so much conceptual as procedural and historical. All consideration of the (non-standard) use of origin/position on div and p has been interpreted as creating a new region, and that is how it has been described in Change Proposal 2 [1] as well as drafted in TTML2 for some time now. It is only since Nigel raised the idea of treating origin/extent on a content element as an anonymous animation to the current region, that this alternative interpretation has arisen.

[1] https://www.w3.org/wiki/TTML/changeProposal002

I would also note that while re-reading this change proposal, there appears
to be a discrepancy in that it employs nested block-containers in the
resulting XSL-FO example. Such usage is not dictated by either TTML1 or
current TTML2 text.

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

[palemieux]

All consideration of the (non-standard) use of origin/position on div and p has been
interpreted as creating a new region, and that is how it has been described in Change
Proposal 2 [1] as well as drafted in TTML2 for some time now.

Would the anonymous region created in the example inherit tts:backgroundColor="transparent" from pop1?

[skynavga]

On Tue, Aug 23, 2016 at 3:29 PM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

All consideration of the (non-standard) use of origin/position on div and
p has been
interpreted as creating a new region, and that is how it has been
described in Change
Proposal 2 [1] as well as drafted in TTML2 for some time now.

Would the anonymous region created in the example
#168 (comment) inherit
tts:backgroundColor="transparent" form pop1?

No. However, the effect would be the same, since the initial value of
tts:backgroundColor is transparent (though this initial value may be
modified in TTML2, but not TTML1).

The semantics of an implied anonymous region is equivalent to:

• specifying a region as a child of the layout element with an
  auto-generated xml:id value R
• specifying a region="R" on the element that causes the creation of
  the anonymous region

So, since regions don't inherit styles from other regions in TTML, the
anonymous region would not inherit.

Furthermore, actually specifying an @region attribute on an element that
causes the creation of an anonymous region is effectively a semantic error
(and needs to be documented as such).

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

[jasonliv]

Hello all,

Pierre asked me to comment on this issue as an implementer. I have not had time to read through the entire issue yet so my apologies if I've missed anything.

His question:

does adding tts:origin (a) merely modify the position of the region selected by <p> or (b) create a brand new region?
If (a), then there is a potential ambiguity if multiple <p> attempt to modify the same region simultaneously.
If (b), then styles defined on any region referenced by the <p> will be lost.

My reply:

In our case (a) will work since the <p> elements we create should never attempt to reference the same region more than once in the same time interval. (If we did I would consider that our bug.)

But I suppose (b) is possible if you assume that this creates an anonymous region which inherits all the attributes (style etc.) from the referenced region, then applies any new attributes set by the <p>.

I hope this helps.

Jason Livingston - Telestream

[skynavga]

On Wed, Aug 24, 2016 at 5:24 PM, jasonliv notifications@github.com wrote:

Hello all,

Pierre asked me to comment on this issue as an implementer. I have not had
time to read through the entire issue yet so my apologies if I've missed
anything.

His question:

does adding tts:origin (a) merely modify the position of the region
selected by

or (b) create a brand new region?
If (a), then there is a potential ambiguity if multiple

attempt to
modify the same region simultaneously.
If (b), then styles defined on any region referenced by the

will be
lost.

My reply:

In our case (a) will work since the

elements we create should never
attempt to reference the same region more than once in the same time
interval. (If we did I would consider that our bug.)

But I suppose (b) is possible if you assume that this creates an anonymous
region which inherits all the attributes (style etc.) from the referenced
region, then applies any new attributes set by the

.

Does the content you generate/consume that specifies origin/extent on p/div
also reference a region from the same p/div? If yes, then does your
implementation effectively apply origin/extent to the referenced region,
overriding any origin/extent already specified on that region?

I hope this helps.

Jason Livingston - Telestream

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

[JLBirch]

Pierre asked me to add my comments to this thread...I've also had an email discussion with him :-)

Although we do not have an active implementation using origin and extent within a

element our view is similar to Jason from Telestream, in that this should affect the 'existing region' referenced either directly or indirectly by that p element. The creation of an anonymous region would surely otherwise contradict any deliberate references to a specific region that was made within that same element? An anonymous region currently would not inherit the existing style attribute tree - potentially leading to some very odd visual effects?

However if the anonymous region was a 'deep copy' of the existing region then this issue might be avoided?

In general we would view the use of extent and origin within a p element (and a span) as a shorthand for set animation (we feel that the shorthand should also be available within a span element as p elements have an inherent line break, thus precluding them from being used to add content to an existing line). This 'shorthand' would be useful to support cumulative subtitling where arguably the region extent (and origin) could be modified as content is added to rows. The modification of origin might also be useful for certain forms of 'subtitling' e.g. Japanese Telop - however, in this specific case a smooth animation is probably more desirable..

best,
John Birch
Screen Systems Ltd

[skynavga]

On Thu, Aug 25, 2016 at 5:21 AM, JLBirch notifications@github.com wrote:

Pierre asked me to add my comments to this thread...I've also had an email
discussion with him :-)

Although we do not have an active implementation using origin and extent
within a

element our view is similar to Jason from Telestream, in that this should
affect the 'existing region' referenced either directly or indirectly by
that p element. The creation of an anonymous region would surely otherwise
contradict any deliberate references to a specific region that was made
within that same element? An anonymous region currently would not inherit
the existing style attribute tree - potentially leading to some very odd
visual effects?

Note that the current specification for anonymous regions is a syntactic
shorthand for specifying an inline region, which prohibits specifying
another region on the same element.

In other words,

is a shorthand for

The proposal being considered here is to additionally support a mode where
this shorthand would translate instead to:

Here, a region could be specified on the source p, e.g.,

which would translate to:

The proposal is to have a ttp:impliedRegionMethod parameter (with values
new|current, default of new) which allows the author to choose which
mode/method applies (on a global document basis).

Note that if an author does want to specify more styles on a new region,
then they can simply use the inline region form, e.g.:

Or can simply reference an out-of-line style specification to pick up the
other styles:

<style xml:id="commonInlineRegionStyles" {*other region specific styles*}/> ...

However if the anonymous region was a 'deep copy' of the existing region
then this issue might be avoided?

In general we would view the use of extent and origin within a p element
(and a span) as a shorthand for set animation (we feel that the
shorthand should also be available within a span element as p elements have
an inherent line break, thus precluding them from being used to add content
to an existing line). This 'shorthand' would be useful to support
cumulative subtitling where arguably the region extent (and origin) could
be modified as content is added to rows. The modification of origin might
also be useful for certain forms of 'subtitling' e.g. Japanese Telop -
however, in this specific case a smooth animation is probably more
desirable..

best,
John Birch
Screen Systems Ltd

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

[JLBirch]

In EBU-TT all regions are 'OutOfLine' regions because there is no possibility of an explicit inline definition. In this case, with the default behaviour of 'new', there would thus presumably be no place to re-iterate the styles onto any new anonymous region? Consequently the default behaviour of TTML, when applied to EBU-TT would mean that use of tts:extent and or tts:origin on a p element could only ever create an anonymous region with default style attributes? Is that correct?

Given that this is unlikely to be a desirable outcome, it would seem that EBU-TT would need to redefine the default value for ttp:impliedRegionMethod to 'current'.

[skynavga]

On Thu, Aug 25, 2016 at 9:37 AM, JLBirch notifications@github.com wrote:

In EBU-TT all regions are 'OutOfLine' regions because there is no
possibility of an explicit inline definition. In this case, with the
default behaviour of 'new' there would thus presumably be no place to
re-iterate the styles onto any new anonymous region? Consequently the
default behaviour of TTML, when applied to EBU-TT would mean that use of
tts:extent and or tts:origin on a element could only ever create an
anonymous region with default style attributes? Is that correct?

Keep in mind we are talking about TTML2 here. Any use of extent/origin on
p/div in a TTML1 based EBU-TT would remain extrajudicial, as it were, at
least as far as TTML1 is concerned.

Given that this is unlikely to be a desirable outcome, it would seem that
EBU-TT would need to redefine the default value for ttp:impliedRegionMethod
to 'current'.

The default values of @ttp:* cannot be redefined in TTML2. But we haven't
made a firm decision yet on a default value yet, so it is still possible
that we may choose 'current' as the default.

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

[nigelmegitt]

Notes from 2016-09-20 f2f meeting: making inline anonymous regions be modifications to the current region using an anonymous set element requires that the anonymous set references the region, which is a reversal of direction of reference compared to what is there now. However this may also facilitate a solution to #128 by permitting conditional set elements to set region or style attributes based on e.g. media queries or externally passed in parameters.

[palemieux]

See the following CR comment against IMSC1, which asks for @tts:origin to be equivalent to <set>: https://lists.w3.org/Archives/Public/public-tt/2014Oct/0010.html

[nigelmegitt]

Marking as discussed and agreed since we got to that state on the equivalent TTML1 issue w3c/ttml§#194.

[nigelmegitt]

Sorry these are in fact not exactly equivalent issues, reverting.

[skynavga]

After further consideration, I've decided to adopt option 2 from the initial comment for this issue, about which see PR #350. I also added tts:disparity to the short list of style attributes that invoke this exceptional behavior.