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

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