Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay

On Mon, Jun 23, 2014 at 1:43 AM, John Birch <John.Birch@screensystems.tv>
wrote:

>  As an aside, what would be the impact on conditional region use? Where
> would content end up if the original target region was removed by a
> condition? I can see how it might end up in a parent region, but in the
> absence of a higher level parent region it would move to a default region?
>

We would have to address this in spec text either way. It would also be
possible to define a ttp parameter that let the author choose the behavior:
no region or default region.


>
> Best regards,
> John
>
>
>  *From*: Glenn Adams [mailto:glenn@skynav.com]
> *Sent*: Monday, June 23, 2014 08:15 AM
>
> *To*: John Birch
> *Cc*: pal@sandflow.com <pal@sandflow.com>; public-tt@w3.org <
> public-tt@w3.org>
> *Subject*: Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay
>
>  In that case, my original proposal to use @condition on content elements
> should suffice, since it would have the same effect as tts:display in the
> sense of including/excluding a content element in the layout/flow process.
>
>  Nevertheless, I can fathom uses for such a conditional to be applied to
> not only content elements, but also region, as well as styling. For the
> purpose of conditionalizing styling, applying it to <set/> seems the best
> option.
>
>
> On Sun, Jun 22, 2014 at 11:46 PM, John Birch <John.Birch@screensystems.tv>
> wrote:
>
>> Agreed re content selection. I am unaware of an example where preserving
>> layout is relevant... Or would be absolutely necessary.
>>
>> So yes... I believe that the use case can be supported using display.
>>
>> best regards,
>> John
>>
>>
>>
>>  *From*: Glenn Adams [mailto:glenn@skynav.com]
>> *Sent*: Monday, June 23, 2014 06:28 AM
>> *To*: John Birch
>> *Cc*: pal@sandflow.com <pal@sandflow.com>; public-tt@w3.org <
>> public-tt@w3.org>
>> *Subject*: Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay
>>
>>
>> On Sun, Jun 22, 2014 at 11:14 PM, John Birch <John.Birch@screensystems.tv
>> > wrote:
>>
>>> Whilst it may be less problematic for IMSC to diverge from TTML1 I do
>>> have more problems with it not being a subset of TTML2. My preference would
>>> be for a solution that is compatible.
>>>
>>> On the forcedDisplay point I do believe that this represents a content
>>> classification rather than a stylistic attribution... Albeit poorly named.
>>> I.e. Forced subtitles are content that is different to 'normal'
>>> subtitles... As Pierre has illustrated, they are often used for
>>> translations of on-screen texts, or for translations of invented languages
>>> (e.g. Klingon or Navi). They are a sub classification of subtitle. I am
>>> however struggling to think of a better term than 'forced subtitles' as
>>> other alternatives are narrower in scope.
>>>
>>> Consequently I suggest that these are handled as a content
>>> categorisation that invokes a specific style. Possibly a new style
>>> attribute value is needed: visibility = 'forced'.
>>>
>>
>>  From the examples I've seen so far, this is a content selection (as in
>> active or not active) issue rather than a style (visibility) issue. That
>> is, I haven't seen any examples where it should map to tts:visible as
>> opposed to tts:display.
>>
>>  I think we should not disconnect this issue from that of how to treat
>> content tagged with different languages. Furthermore, we could use the
>> @condition approach to dynamically select different region extent/origin
>> based on media device features.
>>
>>
>>>
>>> Best regards,
>>> 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
>>> Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand 5E4-01
>>>
>>>
>>> *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 Broadcast Asia, Marina Bay Sands, Singapore 17-20 June,
>>> Stand 5E4-01*
>>>
>>> *P** Before printing, think about the environment*
>>>
>>>
>>> *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 Broadcast Asia, Marina Bay Sands, Singapore 17-20 June,
>>> Stand 5E4-01*
>>>
>>> *P** Before printing, think about the environment*
>>>
>>>
>>> P Before printing, think about the environment----- Original Message
>>> -----
>>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
>>> Sent: Monday, June 23, 2014 04:55 AM
>>> To: Glenn Adams <glenn@skynav.com>
>>> Cc: public-tt@w3.org <public-tt@w3.org>
>>> Subject: Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay
>>>
>>> > If you want to define it in IMSC1 as a style attribute that will map
>>> to a future conditional
>>> > style construct in TTML2, then that is fine, but there is no guarantee
>>> we will directly support
>>> > that attribute in TTML2 (as opposed to requiring that the more general
>>> mechanism be used). As it is,
>>> > IMSC1 is likely not going to be a strict subset of either TTML1 or
>>> TTML2.
>>>
>>> Sounds like a reasonable approach.
>>>
>>> Best,
>>>
>>> -- Pierre
>>>
>>> On Sun, Jun 22, 2014 at 8:45 PM, Glenn Adams <glenn@skynav.com> wrote:
>>> > Do you have a real world example of where conditional content couldn't
>>> > handle it? In any case, I think we can define a conditional styling
>>> > mechanism as well as conditional content, and then author can choose
>>> the one
>>> > that makes sense.
>>> >
>>> > If you want to define it in IMSC1 as a style attribute that will map
>>> to a
>>> > future conditional style construct in TTML2, then that is fine, but
>>> there is
>>> > no guarantee we will directly support that attribute in TTML2 (as
>>> opposed to
>>> > requiring that the more general mechanism be used). As it is, IMSC1 is
>>> > likely not going to be a strict subset of either TTML1 or TTML2.
>>> >
>>> >
>>> > On Sun, Jun 22, 2014 at 9:42 PM, Pierre-Anthony Lemieux <
>>> pal@sandflow.com>
>>> > wrote:
>>> >>
>>> >> > In this example, the conditional content would suffice, since there
>>> >> > is no layout interaction between the two regions.
>>> >>
>>> >> Perhaps, but this cannot be guaranteed to be always the case.
>>> >>
>>> >> -- Pierre
>>> >>
>>> >> On Sun, Jun 22, 2014 at 8:40 PM, Glenn Adams <glenn@skynav.com>
>>> wrote:
>>> >> > In this example, the conditional content would suffice, since there
>>> is
>>> >> > no
>>> >> > layout interaction between the two regions.
>>> >> >
>>> >> >
>>> >> > On Sun, Jun 22, 2014 at 9:31 PM, Pierre-Anthony Lemieux
>>> >> > <pal@sandflow.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi Glenn,
>>> >> >>
>>> >> >> Attached is an example inspired from an opening shot from The
>>> Muppets
>>> >> >> (2011) Blu-Ray.
>>> >> >>
>>> >> >> The forced subtitle is the translation of the "High School" sign.
>>> It
>>> >> >> appears when French is selected as the language, even if the user
>>> has
>>> >> >> not explicitly selected French subtitles, i.e. when 'forced mode'
>>> is
>>> >> >> true.
>>> >> >>
>>> >> >> The translation of the voiceover is not labeled 'forced', and thus
>>> >> >> shows up only when French subtitles are selected, i.e. 'forced
>>> mode'
>>> >> >> is false.
>>> >> >>
>>> >> >> Best,
>>> >> >>
>>> >> >> -- Pierre
>>> >> >>
>>> >> >> P.S.: in UVVU, 'forced mode'=='true' is called "Alternate
>>> Subtitling
>>> >> >> Presentation Mode" and 'forced mode'=='false' is called "Primary
>>> >> >> Subtitling Presentation Mode".
>>> >> >>
>>> >> >> On Sat, Jun 21, 2014 at 7:17 PM, Glenn Adams <glenn@skynav.com>
>>> wrote:
>>> >> >> > Could you point at or construct a real world example, i.e.,
>>> images of
>>> >> >> > what a
>>> >> >> > mixture of forced and non-forced content looks like depending on
>>> >> >> > whether
>>> >> >> > a
>>> >> >> > forced display parameter is true or false?
>>> >> >> >
>>> >> >> >
>>> >> >> > On Sat, Jun 21, 2014 at 6:56 PM, Pierre-Anthony Lemieux
>>> >> >> > <pal@sandflow.com>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> Hi Glenn,
>>> >> >> >>
>>> >> >> >> > why would one want it to occupy layout space if not selected?
>>> >> >> >> > that doesn't make any sense;
>>> >> >> >>
>>> >> >> >> The forced content would have been positioned with the
>>> non-forced
>>> >> >> >> content present. Simply removing the non-forced content from
>>> flow
>>> >> >> >> would potentially change the rendered position of the forced
>>> >> >> >> content.
>>> >> >> >>
>>> >> >> >> I will confirm this.
>>> >> >> >>
>>> >> >> >> Best,
>>> >> >> >>
>>> >> >> >> -- Pierre
>>> >> >> >>
>>> >> >> >> On Sat, Jun 21, 2014 at 5:50 PM, Glenn Adams <glenn@skynav.com>
>>> >> >> >> wrote:
>>> >> >> >> >
>>> >> >> >> > On Sat, Jun 21, 2014 at 6:43 PM, Pierre-Anthony Lemieux
>>> >> >> >> > <pal@sandflow.com>
>>> >> >> >> > wrote:
>>> >> >> >> >>
>>> >> >> >> >> Hi Glenn,
>>> >> >> >> >>
>>> >> >> >> >> Thanks for these initial thoughts.
>>> >> >> >> >>
>>> >> >> >> >> > 3. evaluating this sub-tree in a postorder traversal, prune
>>> >> >> >> >> > elements
>>> >> >> >> >> > if they are not a content element, if they have a condition
>>> >> >> >> >> > attribute
>>> >> >> >> >> > that evaluates to false,
>>> >> >> >> >>
>>> >> >> >> >> "Forced" does not remove the content element from layout and
>>> >> >> >> >> flow,
>>> >> >> >> >> but
>>> >> >> >> >> instead
>>> >> >> >> >> effectively sets the visibility to zero, like
>>> >> >> >> >> tts:visibility="hidden".
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > it should; why would one want it to occupy layout space if not
>>> >> >> >> > selected?
>>> >> >> >> > that doesn't make any sense;
>>> >> >> >> >
>>> >> >> >> > i don't see how to handle conditional content and conditional
>>> >> >> >> > visibility; i
>>> >> >> >> > think the best you will get is the former
>>> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> Best,
>>> >> >> >> >>
>>> >> >> >> >> -- Pierre
>>> >> >> >> >>
>>> >> >> >> >> On Sat, Jun 21, 2014 at 5:38 PM, Glenn Adams <
>>> glenn@skynav.com>
>>> >> >> >> >> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > On Sat, Jun 21, 2014 at 6:07 PM, Pierre-Anthony Lemieux
>>> >> >> >> >> > <pal@sandflow.com>
>>> >> >> >> >> > wrote:
>>> >> >> >> >> >>
>>> >> >> >> >> >> > What do you mean by "application" in this context?
>>> >> >> >> >> >>
>>> >> >> >> >> >> The entity that is instructing the presentation processor
>>> to
>>> >> >> >> >> >> render
>>> >> >> >> >> >> the IMSC document.
>>> >> >> >> >> >>
>>> >> >> >> >> >> > I also don't know what parameter means in this context,
>>> >> >> >> >> >> > e.g., what does it mean vis-a-vis a TTML parameter,
>>> i.e.,
>>> >> >> >> >> >> > an attribute expressing a TTML parameter.
>>> >> >> >> >> >>
>>> >> >> >> >> >> It is not a TTML parameter, as in a ttp:*, but instead a
>>> state
>>> >> >> >> >> >> variable passed to the presentation processor instructing
>>> it
>>> >> >> >> >> >> to
>>> >> >> >> >> >> render
>>> >> >> >> >> >> or not non-forced content, like a function argument in a
>>> >> >> >> >> >> procedural
>>> >> >> >> >> >> language.
>>> >> >> >> >> >>
>>> >> >> >> >> >> > I am opposed to a one-off solution to a special case of
>>> the
>>> >> >> >> >> >> > conditional
>>> >> >> >> >> >> >  content problem. And the forcedDisplay feature is
>>> exactly
>>> >> >> >> >> >> > such
>>> >> >> >> >> >> > a
>>> >> >> >> >> >> > special case.
>>> >> >> >> >> >>
>>> >> >> >> >> >> Can you think of a generic solution that would reduce to a
>>> >> >> >> >> >> single
>>> >> >> >> >> >> attribute controlling the rendering of forced content? If
>>> so,
>>> >> >> >> >> >> we
>>> >> >> >> >> >> could
>>> >> >> >> >> >> consider using it in IMSC.
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > I haven't given it much thought, but if we were to
>>> introduce as
>>> >> >> >> >> > the
>>> >> >> >> >> > general
>>> >> >> >> >> > mechanism a new element type:
>>> >> >> >> >> >
>>> >> >> >> >> > <tt:switch condition="expression">
>>> >> >> >> >> > ... content elements ...
>>> >> >> >> >> > </tt:switch>
>>> >> >> >> >> >
>>> >> >> >> >> > then we could also, or as an alternative, introduce an
>>> >> >> >> >> > attribute
>>> >> >> >> >> > @condition
>>> >> >> >> >> > on content element vocabulary, e.g.,
>>> >> >> >> >> >
>>> >> >> >> >> > <div condition="expression"/>
>>> >> >> >> >> >
>>> >> >> >> >> > where expression uses a simple expression language such as
>>> >> >> >> >> > media
>>> >> >> >> >> > queries
>>> >> >> >> >> > level 4 [1] or a derivative.
>>> >> >> >> >> >
>>> >> >> >> >> > [1] http://dev.w3.org/csswg/mediaqueries4/
>>> >> >> >> >> >
>>> >> >> >> >> > For example,
>>> >> >> >> >> >
>>> >> >> >> >> > <p condition="(forced)"/>
>>> >> >> >> >> >
>>> >> >> >> >> > <p condition="not (forced)"/>
>>> >> >> >> >> >
>>> >> >> >> >> > <p condition="(locale: en)"/>
>>> >> >> >> >> >
>>> >> >> >> >> > <p condition="not (locale: en)"/>
>>> >> >> >> >> >
>>> >> >> >> >> > <p condition="(forced) or not (locale: en)"/>
>>> >> >> >> >> >
>>> >> >> >> >> > ...
>>> >> >> >> >> >
>>> >> >> >> >> > Where the semantics of @condition is essentially changing
>>> step
>>> >> >> >> >> > 3
>>> >> >> >> >> > of
>>> >> >> >> >> > 9.3.3
>>> >> >> >> >> > [construct intermediate document] to read essentially as
>>> >> >> >> >> > follows:
>>> >> >> >> >> >
>>> >> >> >> >> > 3. evaluating this sub-tree in a postorder traversal, prune
>>> >> >> >> >> > elements
>>> >> >> >> >> > if
>>> >> >> >> >> > they
>>> >> >> >> >> > are not a content element, if they have a condition
>>> attribute
>>> >> >> >> >> > that
>>> >> >> >> >> > evaluates
>>> >> >> >> >> > to false, if they are temporally inactive, if they are
>>> empty,
>>> >> >> >> >> > or
>>> >> >> >> >> > if
>>> >> >> >> >> > they
>>> >> >> >> >> > aren't associated with region R according to the [associate
>>> >> >> >> >> > region]
>>> >> >> >> >> > procedure;
>>> >> >> >> >> >
>>> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >> >> Thanks,
>>> >> >> >> >> >>
>>> >> >> >> >> >> -- Pierre
>>> >> >> >> >> >>
>>> >> >> >> >> >> On Fri, Jun 20, 2014 at 10:56 PM, Glenn Adams
>>> >> >> >> >> >> <glenn@skynav.com>
>>> >> >> >> >> >> wrote:
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On Fri, Jun 20, 2014 at 10:33 PM, Pierre-Anthony Lemieux
>>> >> >> >> >> >> > <pal@sandflow.com>
>>> >> >> >> >> >> > wrote:
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> Hi Glenn,
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> Thanks for the feedback.
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> > no, [forcedDisplayModeParameter] should not be a
>>> >> >> >> >> >> >> > parameter,
>>> >> >> >> >> >> >> > in
>>> >> >> >> >> >> >> > which
>>> >> >> >> >> >> >> > it would go into some
>>> >> >> >> >> >> >> > parameter namespace, but should be a metadata
>>> attribute,
>>> >> >> >> >> >> >> > ittm:forcedDisplay
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> forcedDisplayModeParameter != itts:forcedDisplay.
>>> >> >> >> >> >> >> forcedDisplayModeParameter would be a parameter passed
>>> by
>>> >> >> >> >> >> >> the
>>> >> >> >> >> >> >> application to the processor, not a parameter within
>>> the
>>> >> >> >> >> >> >> document.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > What do you mean by "application" in this context? I
>>> also
>>> >> >> >> >> >> > don't
>>> >> >> >> >> >> > know
>>> >> >> >> >> >> > what
>>> >> >> >> >> >> > parameter means in this context, e.g., what does it mean
>>> >> >> >> >> >> > vis-a-vis
>>> >> >> >> >> >> > a
>>> >> >> >> >> >> > TTML
>>> >> >> >> >> >> > parameter, i.e., an attribute expressing a TTML
>>> parameter.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> > in other words, TTML will remain silent on any
>>> >> >> >> >> >> >> > presentation
>>> >> >> >> >> >> >> > semantics
>>> >> >> >> >> >> >> > of
>>> >> >> >> >> >> >> > such an attribute;
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> How would interoperability be achieved?
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > By defining a standard mechanism for expressing
>>> conditional
>>> >> >> >> >> >> > content
>>> >> >> >> >> >> > contingent on external processor state, e.g., selected
>>> >> >> >> >> >> > language,
>>> >> >> >> >> >> > whether
>>> >> >> >> >> >> > display of some content is forced or not, etc.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > I am opposed to a one-off solution to a special case of
>>> the
>>> >> >> >> >> >> > conditional
>>> >> >> >> >> >> > content problem. And the forcedDisplay feature is
>>> exactly
>>> >> >> >> >> >> > such
>>> >> >> >> >> >> > a
>>> >> >> >> >> >> > special
>>> >> >> >> >> >> > case.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> Thanks,
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> -- Pierre
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> On Fri, Jun 20, 2014 at 8:58 PM, Glenn Adams
>>> >> >> >> >> >> >> <glenn@skynav.com>
>>> >> >> >> >> >> >> wrote:
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > On Fri, Jun 20, 2014 at 7:05 PM, Pierre-Anthony
>>> Lemieux
>>> >> >> >> >> >> >> > <pal@sandflow.com>
>>> >> >> >> >> >> >> > wrote:
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> Hi all,
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> During our last call, I noted two concerns with the
>>> >> >> >> >> >> >> >> itts:forcedDisplay
>>> >> >> >> >> >> >> >> feature as currently drafted.
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> (a) the semantics of the itts:forcedDisplay feature
>>> are
>>> >> >> >> >> >> >> >> not
>>> >> >> >> >> >> >> >> sufficiently specified
>>> >> >> >> >> >> >> >> (b) the representation of itts:forcedDisplay as an
>>> >> >> >> >> >> >> >> attribute
>>> >> >> >> >> >> >> >> is
>>> >> >> >> >> >> >> >> not
>>> >> >> >> >> >> >> >> desirable
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > that should read as a style attribute
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> To address (a), below is proposed prose:
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> """
>>> >> >> >> >> >> >> >> The presentation processor SHALL accept an optional
>>> >> >> >> >> >> >> >> boolean
>>> >> >> >> >> >> >> >> parameter
>>> >> >> >> >> >> >> >> called forcedDisplayModeParameter, whose value may
>>> be
>>> >> >> >> >> >> >> >> set
>>> >> >> >> >> >> >> >> by
>>> >> >> >> >> >> >> >> the
>>> >> >> >> >> >> >> >> application. If not set, the value of
>>> >> >> >> >> >> >> >> forcedDisplayModeParameter
>>> >> >> >> >> >> >> >> shall
>>> >> >> >> >> >> >> >> be assumed to be equal to "false".
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > no, it should not be a parameter, in which it would
>>> go
>>> >> >> >> >> >> >> > into
>>> >> >> >> >> >> >> > some
>>> >> >> >> >> >> >> > parameter
>>> >> >> >> >> >> >> > namespace, but should be a metadata attribute,
>>> >> >> >> >> >> >> > ittm:forcedDisplay
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > i'm not sure why you wish to lengthen the name
>>> >> >> >> >> >> >> > unnecessarily
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> If the value of forcedDisplayModeParameter is
>>> "true", a
>>> >> >> >> >> >> >> >> content
>>> >> >> >> >> >> >> >> element with a itts:forcedDisplay computed value of
>>> >> >> >> >> >> >> >> "false"
>>> >> >> >> >> >> >> >> shall
>>> >> >> >> >> >> >> >> be
>>> >> >> >> >> >> >> >> assumed to have a tts:visibility computed value
>>> equal to
>>> >> >> >> >> >> >> >> "hidden",
>>> >> >> >> >> >> >> >> even if tts:visibility is otherwise set to "true".
>>> >> >> >> >> >> >> >> """
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > now, this is again placing style/presentation
>>> semantics
>>> >> >> >> >> >> >> > on
>>> >> >> >> >> >> >> > this
>>> >> >> >> >> >> >> > metadata
>>> >> >> >> >> >> >> > attribute, which is inapropriate
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> The idea is to essentially ignore the
>>> itts:forcedDisplay
>>> >> >> >> >> >> >> >> attribute
>>> >> >> >> >> >> >> >> unless otherwise specifically requested by the
>>> >> >> >> >> >> >> >> application.
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > i'm not sure what "requested by the application"
>>> means
>>> >> >> >> >> >> >> > here
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> This also
>>> >> >> >> >> >> >> >> clarifies that itts:forcedDisplay has "no effect on
>>> >> >> >> >> >> >> >> content
>>> >> >> >> >> >> >> >> layout
>>> >> >> >> >> >> >> >> or
>>> >> >> >> >> >> >> >> composition, but merely determines whether composed
>>> >> >> >> >> >> >> >> content
>>> >> >> >> >> >> >> >> is
>>> >> >> >> >> >> >> >> visible
>>> >> >> >> >> >> >> >> or not."
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > if that is the purpose, then the tts:visibility
>>> property
>>> >> >> >> >> >> >> > should
>>> >> >> >> >> >> >> > be
>>> >> >> >> >> >> >> > used
>>> >> >> >> >> >> >> > and
>>> >> >> >> >> >> >> > therefore there is no need for a new forcedDisplay
>>> >> >> >> >> >> >> > attribute
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> As next step, I plan to create examples.
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> Re: (b), I am not comfortable rejecting a solution
>>> that
>>> >> >> >> >> >> >> >> users
>>> >> >> >> >> >> >> >> have
>>> >> >> >> >> >> >> >> devised and implemented based on actual use cases
>>> and in
>>> >> >> >> >> >> >> >> the
>>> >> >> >> >> >> >> >> absence
>>> >> >> >> >> >> >> >> of specific guidance and/or prohibition in TTML 1.0.
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > if those users expect that the TTWG would simply
>>> adopt a
>>> >> >> >> >> >> >> > solution
>>> >> >> >> >> >> >> > as
>>> >> >> >> >> >> >> > a
>>> >> >> >> >> >> >> > fait
>>> >> >> >> >> >> >> > accompli, then they are naive; an appropriate process
>>> >> >> >> >> >> >> > would
>>> >> >> >> >> >> >> > have
>>> >> >> >> >> >> >> > been
>>> >> >> >> >> >> >> > to
>>> >> >> >> >> >> >> > bring use cases and requirements to the TTWG first,
>>> not
>>> >> >> >> >> >> >> > bring a
>>> >> >> >> >> >> >> > solution
>>> >> >> >> >> >> >> > as
>>> >> >> >> >> >> >> > a given
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > at this point, I think the best that can be hoped for
>>> >> >> >> >> >> >> > IMSC
>>> >> >> >> >> >> >> > is
>>> >> >> >> >> >> >> > to
>>> >> >> >> >> >> >> > define
>>> >> >> >> >> >> >> > a
>>> >> >> >> >> >> >> > metadata attribute ittm:forcedDisplay which is
>>> described
>>> >> >> >> >> >> >> > as
>>> >> >> >> >> >> >> > a
>>> >> >> >> >> >> >> > hint
>>> >> >> >> >> >> >> > that
>>> >> >> >> >> >> >> > the
>>> >> >> >> >> >> >> > associated content is intended to be selected as a
>>> >> >> >> >> >> >> > candidate
>>> >> >> >> >> >> >> > for
>>> >> >> >> >> >> >> > display
>>> >> >> >> >> >> >> > by
>>> >> >> >> >> >> >> > a higher level protocol (outside the scope of
>>> formally
>>> >> >> >> >> >> >> > defined
>>> >> >> >> >> >> >> > TTML
>>> >> >> >> >> >> >> > processing); in other words, TTML will remain silent
>>> on
>>> >> >> >> >> >> >> > any
>>> >> >> >> >> >> >> > presentation
>>> >> >> >> >> >> >> > semantics of such an attribute;
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > on the other hand, we may choose in TTML2 to define a
>>> >> >> >> >> >> >> > conditional
>>> >> >> >> >> >> >> > content
>>> >> >> >> >> >> >> > mechanism similar to the SMIL or SVG switch element,
>>> that
>>> >> >> >> >> >> >> > could
>>> >> >> >> >> >> >> > address
>>> >> >> >> >> >> >> > this
>>> >> >> >> >> >> >> > use case
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> Best,
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> -- Pierre
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>>
>>>  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
>>     ­­
>>
>
>
>  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
>     ­­
>