RE: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2]

Hi Nigel,

You raise an interesting concept.

I had assumed that support of user preferences within a device, would be implemented by having the device re-writing the input document (effectively creating a new 'ttml' document that is then processed and presented).

I had not considered the creation of documents that effectively contained different parallel versions of content.

I can see why it might be thought useful to pre-define variations at authoring, in order to avoid potential presentation problems (e.g. inappropriate text wrapping or overflow).
However my feeling is that the number of combinations that occur, even when only allowing for only a few style attributes to vary in value, quickly makes pre-definition, *for the purpose of assuring reasonable presentation*, a significant issue.
In addition, *programmatically* determining what is a 'reasonable presentation' is a hard problem.

This question is one that we have been thinking about for some time and in the Hbb4All project, where Screen are looking at this type of issue (for user preferences on 'magazine' page content), we are currently looking at implementing a 'half and half' approach. Those 'user preferences' that affect layout we will most probably handle by serving completely different content to the device (the server determines which content to serve using a cookie for the user preferences passed up to the server). The 'user preferences' that do not affect layout (e.g. colour choices) will probably be handled in the device by re-mapping. To side step the 'reasonable presentation' problem we will constrain the document authors to using template layouts, where the different variants (to support 'user preferences') will be pre-designed to intrinsically cope with the same raw content.

For example, for a given 'base' page template, the large text variant of the template would have smaller graphics or use 'sub-pages' to ensure that the screen 'real estate' available for text was the correct ratio larger than the 'normal' base page template.... i.e. if the large text template variant is to support a user text preference that is 140% of normal, the regions for text within the page would be 140% (or more) of the size of those regions in the base template (at the expense of other elements on the base template (like graphics or headers)).

So a page that looked like this in base template:

------ Title of this page ------
Text here ttt XXXXXXXXXX
tttt tt  ttttt t  XXXXXXXXXX
tt ttt tttt tttt XXXXXXXXXX
tt tttt tt t ttt  XXXXXXXXXX
tt tttt tt t ttt  tt tttt tt t ttt
tt tttt tt t ttt  tt tttt tt t ttt
tt tttt tt t ttt  tt tttt tt t ttt

where XXXXXXX is a picture

might look like this in the large text template.

-- T i t l e  o f  t h i s      ------
----  p a g e                     ------
T e x t  h e r e   t t t  t
t t t t   t t   t t t t t   t t t

I appreciate this is not 'subtitling', or even timed text specific, but thought that might be of some interest....

Best regards,

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

Visit us at
BVE, Excel London 24-26 February 2015 Stand No. N19

P Before printing, think about the environment-----Original Message-----
From: Timed Text Working Group Issue Tracker []
Sent: 16 January 2015 09:53
Subject: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2]

ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2]

Raised by: Nigel Megitt
On product: TTML2

Consider the use case in which an author wishes to permit the viewer of a TTML2 document to select from one of a number of style choices, either depending on a parameter or a media query, for example choices that vary tts:fontSize and tts:extent to accommodate 'normal size font', 'large size font' and 'small size font' options.

The condition attribute can only be used to omit an element from semantic processing, not to change its behaviour. One might imagine that the following is a way to proceed:

<region xml:id="r1" condition="parameter(text_size)=='large size font'" tts:extent="95vw 30vh" .../> <region xml:id="r1" condition="parameter(text_size)=='normal size font'" tts:extent="80vw 20vh" .../> <region xml:id="r1" condition="parameter(text_size)=='small size font'" tts:extent="60vw 15vh" .../> </layout> <styling> <style xml:id="sFontSize" condition="parameter(text_size)=='large size font'" tts:fontSize="15vh"/> <style xml:id="sFontSize" condition="parameter(text_size)=='normal size font'" tts:fontSize="10vh"/> <style xml:id="sFontSize" condition="parameter(text_size)=='small size font'" tts:fontSize="7.5vh"/> <style xml:id="sDefaultFont" style="sFontSize" tts:fontFamily="myFontFamily"/> </styling>


<div region="r1" style="sDefaultFont">

However this construct, which requires use of xml:id for style and region reference, breaks xml:id uniqueness rules, resulting in invalid documents. What options are there for achieving this use case? I can see:

a) repeating all the content in the document with different style and region references and specifying condition only on the content,

b) basing everything on the initial element and making that conditional (since nothing needs to refer to initial by xml:id), and specifying all regions inline - unfortunately this may be very verbose in terms of repeating regions on many content elements, but it could work for cases where there are only a few regions and they can be associated with body or div elements.

Neither of these two options is particularly attractive - a) is highly repetitious and offers no advantage over the provision of multiple documents with any associated costs for asset management and distribution there. b) is limited in basing style on initial so it is a 'one chance' condition, and it is potentially repetitious in region definition.

By the way, there are at least three audience groups for which this use case exists: 1) Those who have reading difficulties with normal size text; 2) users of different devices, where it has been established that text needs to be rendered at different sizes on large screen televisions from smartphones for example; 3) those who just want to be able to customise the display.

It would be great if the condition construct could be used to allow some predefined viewing options to be authored into the document, i.e. in a controlled way by the document author. I can't see how this can be achieved at present though.

What solution choices are there? Perhaps the easiest is to redefine the condition construct so that it also includes an 'if then else if' syntax in which attributes can be defined, so you might end up with, for example:

<region xml:id="r1" condition="if parameter(text_size)=='large size font' then (tts:extent='95vw 30vh' elseif parameter(text_size)='normal size font' then (tts:extent='80vw 20vh') elseif parameter(text_size)='small size font' then (tts:extent='60vw 15vh') else (tts:extent='80vw 20vh')"/>

Then xml:id rules are not broken and region r1 can be referenced safely with the attribute evaluation only being conditional. I'd advocate retaining the ability to specify a condition that can be used to exclude the entire element from semantic processing, as now.

Another solution to this problem might be to define some preprocessing using XPath to select specific elements and/or attributes and set values on the basis of the same condition functions that have already been specified, i.e. parameter, media, supports. Something like:

<tt:tt [parameters etc]>
   <rule condition="parameter(text_size)=='large size text'" path="//region[@xml:id='r1']">
      <attributes tts:extent="95vw 30vh">
   <layout><region xml:id="r1"/></layout> ...

It would be an error for a path attribute to refer to anywhere except <head> or <body> or their descendants.

This option would also have the incidental effect that it would provide similar functionality to declarative styling. All the rules would be executed in document order prior to processing the <head>. Preprocessing could of course also be performed externally to the document before processing, if a 'user style' is desirable (as is the case for any XML document) .

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

Received on Friday, 16 January 2015 11:03:32 UTC