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

AFAIK, in addition to UVVU content, there is a large body of existing
subtitle content that combines forced and non-forced content in a
single stream. See [1] for a list of Blu Ray discs with that feature.

[1] https://docs.google.com/spreadsheet/ccc?key=0AkGO8UqErL6idDhYYjg1ZXlORnRaM3ZhTks4Z3FrYlE&usp=sharing#gid=12

Best,

-- Pierre

On Fri, Jun 20, 2014 at 9:04 PM, Glenn Adams <glenn@skynav.com> wrote:
> 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
>>>
>>
>

Received on Saturday, 21 June 2014 04:41:57 UTC