Re: TTML2 anonymous inline region creation

Thanks for that Glenn - that was my logic also when I looked at this yesterday, and I think we came up with the same lists.

When I applied this thinking to tts:disparity it seemed to me extremely unlikely that anyone would want to create a new region based on a new disparity – I thought it more likely that the desired behaviour is to modify the disparity of the current region, since the 3D examples I have seen have actively moved the apparent distance forward and backward to track the objects in the video, which is what is needed to make them watchable. I asserted that it is also true for origin, extent, position and zIndex because on the same basis regions may be translated or stretched to follow objects in related media in two dimensions. Creating new regions for every new p could lead to weird effects if using this technique.

>> I believe your proposal is more in line with users expectations.
>> Viz: A user probably has the expectation that a region style attribute that is specified on a p element has an effect on the region that is associated with that p element.
> pure speculation, nothing to suggest this in fact
Is there any evidence here either way? I'm not sure how strongly we should take the example of the existing prior use (misuse?) of tts:origin and tts:extent. Can anyone provide more details about what semantic was intended when that syntax was adopted?
Nigel


From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Wednesday, 21 October 2015 11:01
To: John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>>
Cc: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>, Timed Text Working Group <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: Re: TTML2 anonymous inline region creation

Allow me to elaborate further why it is impractical to allow any style property that can apply to a region to trigger an anonymous region (AR):

If a style applies both to a region and to {div,p}, then that style's semantics becomes ambiguous when it also is intended to trigger AR generation (and by means of which, apply to that region). For example, the following properties apply (independently) both to region and to {div,p}:

  *   tts:backgroundColor
  *   tts:backgroundImage
  *   tts:backgroundPosition
  *   tts:backgroundRepeat
  *   tts:border
  *   tts:display
  *   tts:padding
  *   tts:opacity
  *   tts:visibility

So clearly these must not trigger an AR. This leaves the possibility of having the following (which only apply to region) as a trigger:

  *   tts:disparity
  *   tts:displayAlign
  *   tts:extent
  *   tts:origin
  *   tts:overflow
  *   tts:position
  *   tts:showBackground
  *   tts:writingMode
  *   tts:zIndex

Of these, I believe we are all in agreement that tts:{extent,origin} and probably tts:position should serve as an AR trigger. That leaves the following to consider:

  *   tts:disparity
  *   tts:displayAlign
  *   tts:overflow
  *   tts:showBackground
  *   tts:writingMode
  *   tts:zIndex

At present these only apply to region and not to {div,p}; however, are we certain that we would never apply them to {div,p}? If we aren't certain, then deciding now to make these AR triggers will reduce our ability to widen their semantics in the future to apply to non-region content element types.

We would need to consider each of these in terms as a candidate AR trigger. Further, we need to weigh such usage against the memory load required on the part of the user/author to remember which of these are triggers. IMO it is easier to remember that only a limited number of styles, e.g., {extent,origin,position}, serve as potential AR triggers.


On Wed, Oct 21, 2015 at 3:30 AM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
As I noted in my last reply on this thread, the anonymous region mechanism is no more than a (reduced) syntactic shorthand for an inline region. This was done to support existing, but non-standard usage that came out of a mis-interpretation of what styles applied to what elements. There should be no expectation that this shorthand can be as expressive as its referent, namely as the equivalent inline region. Conclusion: if you want the full expressive power, use an inline region.

On Wed, Oct 21, 2015 at 3:20 AM, John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> wrote:
I have the expectation that the end effect would be as Nigel described (regardless of mechanism).
I.e. I would expect that the ‘anonymous region’ that is actually created would behave and be defined with exactly identical attribute properties to the region strictly associated with the p element (with the replacement of the specified attribute(s). However, due to my prolonged exposure to TTML, I suspect that this is not always the case – and only detailed reading and comprehension of the full standard, and some careful thought, would tell me why and when this might not be the case...

So there is ‘one’ datum… ;-)

J

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
BVE, London Excel, 23-25 February 2016, stand C20

P Before printing, think about the environment

From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>]
Sent: 21 October 2015 10:13
To: John Birch
Cc: Nigel Megitt; Timed Text Working Group
Subject: Re: TTML2 anonymous inline region creation



On Wed, Oct 21, 2015 at 2:43 AM, John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> wrote:
I believe your proposal is more in line with users expectations.

Viz: A user probably has the expectation that a region style attribute that is specified on a p element has an effect on the region that is associated with that p element.

pure speculation, nothing to suggest this in fact


Changing display align dynamically could be useful in the case of a simplistic document using a 'full screen' 'transparent' region. Similarly changing writingMode to support mixed Arabic / Latin might be useful.
Consequently I don't think restricting the scope to specific style attributes is necessary... some cases might be somewhat limited in utility, but it is probably easier to apply the anonymous set concept to all region style attributes.

Best,
John


John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
BVE, London Excel, 23-25 February 2016, stand C20

P Before printing, think about the environment-----Original Message-----
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>]
Sent: 20 October 2015 15:48
To: Timed Text Working Group
Subject: TTML2 anonymous inline region creation

All,

Right now in TTML2 if a style attribute is specified on a p element that only has an effect on regions then an anonymous inline region is created.
The style attribute inheritance chain is:

>initial values -> anonymous region -> body -> div ... -> p -> span ...


In considering how to fix tts:disparity it occurred to me that this isn't always what document authors might want or indeed expect.

Another idea that I'm considering is: change from creating an anonymous inline region to creating an anonymous inline <set> element whose target is the region that applies to the element on which it applies and whose timing is coincident with the timing of the same element.

In case of temporally overlapping elements that set the same style attributes to different values I would resolve the conflict using a begin-time-then-document-order rule, where last one wins.

This would apply to the following style attributes that only have an effect on regions: tts:disparity, tts:extent, tts:origin, tts:position and tts:zIndex. I would probably exclude tts:displayAlign, tts:overflow, tts:showBackground and tts:writingMode because changing those on the fly would be weird.

I'm just thinking this through right now, not definitively proposing it.
The main thing I'm worried about is how the current solution interacts with issue-341 and issue-368. Even if we do go down the route of creating anonymous inline regions I imagine that authors will want a semantic like "just like a template region but with the specified style attributes differing", where the template region is the one that would have applied in the absence of the region-based style attributes on the p. That would also require a change to the inheritance chain, which would then be:

Initial values -> specified region (if any) ... -> anonymous region -> body -> div … -> p -> span …

Any thoughts on this appreciated, even if they're "Aargh don't change it now"!

Nigel



-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
-----------------------------
This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ


This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
  ­­