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
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>

Received on Monday, 23 June 2014 03:56:43 UTC