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

Hi Nigel,

CIL...

Best,
John


John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: 09 July 2014 12:11
To: John Birch; Michael Dolan; 'TTWG'
Subject: Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay

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.
>> Certainly there would be very few additional documents required, but I do not agree that this necessary implies it is the lowest cost approach or the least complex for authoring. I think it is fairly universally agreed that making provisions for special cases in systems, workflows and operational practises often results in considerable costs and, perhaps more relevantly, it disproportionately increases the risk of errors or omissions. My view is that it is such a small requirement that adding it as a 'small wrinkle' in the single document is the most practical resolution.

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.
Very much agree - much more normative and informative text required.

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

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<mailto: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<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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<mailto: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<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<mailto: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<mailto:glenn@skynav.com>]
Sent: Monday, June 23, 2014 5:41 PM
To: John Birch
Cc: pal@sandflow.com<mailto:pal@sandflow.com>; public-tt@w3.org<mailto: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<mailto:glenn@skynav.com>> wrote:

On Mon, Jun 23, 2014 at 1:43 AM, John Birch <John.Birch@screensystems.tv<mailto: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<mailto:glenn@skynav.com>]
Sent: Monday, June 23, 2014 08:15 AM

To: John Birch
Cc: pal@sandflow.com<mailto:pal@sandflow.com> <pal@sandflow.com<mailto:pal@sandflow.com>>; public-tt@w3.org<mailto:public-tt@w3.org> <public-tt@w3.org<mailto: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<mailto: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<mailto:glenn@skynav.com>]
Sent: Monday, June 23, 2014 06:28 AM
To: John Birch
Cc: pal@sandflow.com<mailto:pal@sandflow.com> <pal@sandflow.com<mailto:pal@sandflow.com>>; public-tt@w3.org<mailto:public-tt@w3.org> <public-tt@w3.org<mailto: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<mailto: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<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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<mailto:pal@sandflow.com>]
Sent: Monday, June 23, 2014 04:55 AM
To: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Cc: public-tt@w3.org<mailto:public-tt@w3.org> <public-tt@w3.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:glenn@skynav.com>>
>> >> >> wrote:
>> >> >> >
>> >> >> > On Sat, Jun 21, 2014 at 6:43 PM, Pierre-Anthony Lemieux
>> >> >> > <pal@sandflow.com<mailto: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<mailto:glenn@skynav.com>>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Sat, Jun 21, 2014 at 6:07 PM, Pierre-Anthony Lemieux
>> >> >> >> > <pal@sandflow.com<mailto: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<mailto:glenn@skynav.com>>
>> >> >> >> >> wrote:
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jun 20, 2014 at 10:33 PM, Pierre-Anthony Lemieux
>> >> >> >> >> > <pal@sandflow.com<mailto: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<mailto:glenn@skynav.com>>
>> >> >> >> >> >> wrote:
>> >> >> >> >> >> >
>> >> >> >> >> >> > On Fri, Jun 20, 2014 at 7:05 PM, Pierre-Anthony Lemieux
>> >> >> >> >> >> > <pal@sandflow.com<mailto: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
  ­­