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> 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>
> 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 | Ext : 2208 | Direct Dial : +44 1473 834532
>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>> John.Birch@screensystems.tv | 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]
>> *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>
>> 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 | Ext : 2208 | Direct Dial : +44 1473 834532
>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>> John.Birch@screensystems.tv | 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]
>> 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
>>   ­­
>>
>
>