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

another thought I had, after listening to the discussion about different
tracks for image and text based captions/subtitles, is that the
captions/subtitles to be treated as "force display" should live in a
distinct track (or TTML resource), similar to how one might use distinct
tracks (resources) for different language translations of subtitles;


On Fri, Jun 20, 2014 at 9: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
>>
>>
>