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

On Wed, Jul 9, 2014 at 2:19 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> > 1. Describe in the spec the external context more fully with a system
> model or
> > similar, describing the 4 logical possibilities of none/forced
> only/non-forced
> > only/forced + non-forced.
> > I'd suggest that this is in an introductory section and that parts of
> the description
> > should be informative and other parts may be normative,
>
> Ok. Happy to take a first stab on an Annex. Let me know if you have
> specific text in mind.
>
> > if it is a requirement of IMSC document processors that they maintain an
> > externally set state for the selection of forced/non-forced content then
> > that should be normative. [...]
> > 2. Clarify in the spec whether forcedDisplay maps effectively to a change
> > in the value of the tts:display parameter or the tts:visibility
> parameter.
>
> Below is proposed text:
>
> """
> 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".
>
> 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".
> """
>

Note that this will leave the region presentation visible if it has
tts:showBackground of always, which is the default (i.e., initial value).

Such text should also be accompanied by a note, e.g.,

*Note:* It is expected that the functionality of itts:forcedDisplay will be
mapped to a TTML2 conditional style construct in a future revision of IMSC.


>
> Best,
>
> -- Pierre
>
> On Wed, Jul 9, 2014 at 4:11 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
> > Those figures are interesting John, and they suggest a different
> conclusion
> > to me, i.e. that Glenn's idea that 3 separate resources could meet the
> > different criteria is the simplest – from what you say, in 90-98% of
> cases
> > resource 1 (forced only) would be an empty (reusable?) document and
> > resources 2 and 3 would be identical, so the incremental authoring and
> > management complexity, and storage and transfer costs, would be very low.
> >
> > However I recognise that this does not help with existing work that was
> > based on the use of forcedDisplay; additionally we do have a requirement
> for
> > conditional display that is not met in TTML1 and that we could choose to
> > meet in TTML2. The note in the current editor's draft spec deals with the
> > latter point satisfactorily based on previous discussions.
> >
> > If we are to proceed with forcedDisplay, then we seem to need the
> following
> > changes:
> >
> > 1. Describe in the spec the external context more fully with a system
> model
> > or similar, describing the 4 logical possibilities of none/forced
> > only/non-forced only/forced + non-forced. I'd suggest that this is in an
> > introductory section and that parts of the description should be
> informative
> > and other parts may be normative, i.e. if it is a requirement of IMSC
> > document processors that they maintain an externally set state for the
> > selection of forced/non-forced content then that should be normative.
> >
> > 2. Clarify in the spec whether forcedDisplay maps effectively to a
> change in
> > the value of the tts:display parameter or the tts:visibility parameter.
> >
> > Are there any more actions to resolve issue-312?
> > Who can take these actions?
> >
> > Kind regards,
> >
> > Nigel
> >
> >
> >
> > On 25/06/2014 12:07, "John Birch" <John.Birch@screensystems.tv> wrote:
> >
> > I support ‘forcedDisplay’.
> >
> >
> >
> > In my experience, the percentage of files (read movies / episodes) and
> > consequently documents that might require forced display is very low.
> > Certainly less than 10% and probably nearer 2%.
> >
> > Within those movies or episodes, the percentage of subtitles that would
> > require to be forced is also very low… probably close to 2%.
> >
> >
> >
> > So at best ‘forcedDisplay’ subtitles probably account for less than 0.2%
> of
> > all subtitles authored… and probably it is more likely to be 0.04%.
> >
> >
> >
> > Requiring an additional one or two documents to support such a
> requirement
> > does on balance seem an excessive adherence to a logical principle! But
> hey,
> > that’s just my view!
> >
> >
> >
> >
> >
> >
> >
> > Note I do agree that supporting ‘forcedDisplay’ has interesting
> implications
> > for a processor / decoder (like having to load and conditionally process
> a
> > user *unselected* document!)… so I would suggest that support for a
> > forcedDisplay concept should be an optional feature.
> >
> > In addition, perhaps there should be more information as to how a
> processor
> > should behave in terms of user preferences with regards to forcedDisplay…
> > e.g. which language file (in the case of multiple documents) should it
> load
> > for the forced content? Or is this more fully described in CFF-TT? ;-)
> >
> >
> >
> > 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
> > IBC, RAI Amsterdam, 12-16 Sept, stand 1.C49
> >
> > P Before printing, think about the environment
> >
> >
> > From: Michael Dolan [mailto:mdolan@newtbt.com]
> > Sent: 24 June 2014 17:27
> > To: 'TTWG'
> > Subject: RE: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay
> >
> >
> >
> > …it is more a matter of moving the same amount of complexity around
> between
> > components, it is more a matter of moving the same amount of complexity
> > around between components
> >
> >
> >
> > Yep.  And a different room full of a balance of consumer device
> > manufacturers and content publishers (including the encoder vendors),
> > weighing the complexity options, converged on the currently proposed
> > solution.
> >
> >
> >
> > Regards,
> >
> >
> >
> >                 Mike
> >
> >
> >
> > From: Glenn Adams [mailto:glenn@skynav.com]
> > Sent: Tuesday, June 24, 2014 8:38 AM
> > To: Michael Dolan
> > Cc: TTWG
> > Subject: Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jun 24, 2014 at 9:19 AM, Michael Dolan <mdolan@newtbt.com>
> wrote:
> >
> > The content providers rejected this since they would have to author, QA
> and
> > maintain separate works of duplicated text (in this case 3 documents).
> >
> >
> >
> > An alternative that was considered was to author a single document with
> > “forced” included and at least automate the creation of what you describe
> > below, but that doesn’t remove the need for authoring with the “forced”
> > attribute.
> >
> >
> >
> > And, either way, having 3 subtitles tracks for every one actual content
> > track increases the complexity of subtitle track selection in the
> decoder.
> >
> >
> >
> > Audio and subtitle track selection in International releases containing
> half
> > a dozen languages of both image and text subtitles (substantive
> duplicates
> > to which this would add 2 more for each language) is already arguably too
> > complex.  See § 8.3.4 at [1].
> >
> >
> >
> > Like most discussions of 'complexity', it is more a matter of moving the
> > same amount of complexity around between components. In this case,
> potential
> > complexity includes:
> >
> >
> >
> > (1) the need to create multiple TTML resources representing different
> states
> > of inclusion/exclusion of content based on language, forced display, etc;
> >
> >
> >
> > (2) the need to choose between those resources at decode/render time;
> >
> >
> >
> > In contrast, merging conditionally included/excluded content into a
> single
> > TTML resource requires:
> >
> >
> >
> > (1) correct tagging/marking of conditional content;
> >
> >
> >
> > (2) introducing new spec feature to handle conditional content;
> >
> >
> >
> > (3) requiring decoder/presenter to implement conditional content
> handling;
> >
> >
> >
> > From the perspective of spec writing, the latter is more complex since it
> > requires defining a new relatively complex feature. From the perspective
> of
> > decoder/presenter implementation, the latter is more complex since it
> must
> > implement the conditional content feature.
> >
> >
> >
> > So it seems to come down to the weighing of whether specifying,
> supporting
> > (implementing), and authoring for conditional content is more or less
> > complex than authoring multiple resources each of which have already made
> > all content conditionalization choices and then have the
> decoder/presenter
> > select between them.
> >
> >
> >
> > From my perspective, authoring multiple TTML resources is less complex
> > overall. Of course, one could author a master TTML resource that contains
> > metadata to be used by a later transformation process that splits up that
> > master into the multiple resources needed to create the actual
> distribution
> > (interchange) resources.
> >
> >
> >
> >
> >
> > [1]
> >
> http://www.uvvuwiki.com/doc/sites/default/files/PublicSpecs/Device-1.1.pdf
> >
> >
> >
> >                 Mike
> >
> >
> >
> > From: Glenn Adams [mailto:glenn@skynav.com]
> > Sent: Monday, June 23, 2014 8:04 PM
> > To: Michael Dolan
> > Cc: TTWG
> >
> >
> > Subject: Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay
> >
> >
> >
> > Why not author three documents:
> >
> >
> >
> > (1) with forced content only
> >
> > (2) with non-forced content only
> >
> > (3) with non-forced and forced content combined
> >
> >
> >
> > If subtitles are off, then if external forced parameter false, don't
> > decode/present any of (1) to (3).
> >
> > If subtitles are off, then if external forced parameter true,
> decode/present
> > (1).
> >
> > If subtitles are on, then if external forced parameter false,
> decode/present
> > (2).
> >
> > If subtitles are on, then if external forced parameter true,
> decode/present
> > (3).
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Jun 23, 2014 at 7:15 PM, Michael Dolan <mdolan@newtbt.com>
> wrote:
> >
> > We seem to have lost the details of the use case….
> >
> >
> >
> > The visibility (or not) of text marked as “forced” is inversely signaled
> > external to the document.
> >
> >
> >
> > When the entire document is selected (subtitles=on), “forced” has no
> affect
> > at all (as you note).  When it matters is when the document is “not
> > selected” (subtitles=off), then only the text marked “forced” is
> displayed.
> >
> >
> >
> > There is no other known way to get this behavior except to author two
> > separate documents – one containing all the non-forced text, and one
> > containing only the forced text.  Then:
> >
> >
> >
> > 1.       Subtitles=off – decode only the “forced” document
> >
> > 2.       Subtitles=on – decode both of the documents simultaneously,
> > effectively create merged synchronic documents and then display the
> > composited result.
> >
> >
> >
> > The ramifications of #2 above were rejected by consumer device
> manufacturers
> > as too computationally difficult.
> >
> >
> >
> > Clearer?
> >
> >
> >
> > Maybe there is a more clever way to do this, but it has not emerged
> > elsewhere…
> >
> >
> >
> > Regards,
> >
> >
> >
> >                 Mike
> >
> >
> >
> > From: Glenn Adams [mailto:glenn@skynav.com]
> > Sent: Monday, June 23, 2014 5:41 PM
> > To: John Birch
> > Cc: pal@sandflow.com; public-tt@w3.org
> >
> >
> > Subject: Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay
> >
> >
> >
> > I've been contemplating the forced display logic a bit more, and I'm
> > wondering why we need it at all. If any content is present in a TTML
> input
> > document to a compliant TTML presentation processor, then it must format
> all
> > of the content in accordance with the TTML presentation semantics.
> >
> >
> >
> > That is, if there is some content in a TTML document that someone would
> like
> > to annotate as 'forcedDisplay', then it is already being displayed
> (modulo
> > time activation, tts:display, and tts:visible). In other words, there is
> > nothing other than these three criteria that would cause it to not be
> > displayed. So there is no need for forcing anything.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Jun 23, 2014 at 9:10 AM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> >
> > 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
> >
> >   ­­
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
> >   ­­
>
>