W3C home > Mailing lists > Public > public-tt@w3.org > November 2012

RE: ISSUE-180: regions relative to the root container [DFXP 1.0]

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Mon, 12 Nov 2012 17:36:43 +0000
To: Glenn Adams <glenn@skynav.com>, "Monica Martin (MS OPEN TECH)" <momartin@microsoft.com>
CC: Timed Text Working Group <public-tt@w3.org>, "Michael A Dolan (mdolan@newtbt.com)" <mdolan@newtbt.com>
Message-ID: <E9A92BD0A4FC934EB7935470A46D1524166D0397@DB3EX14MBXC325.europe.corp.microsoft.com>
The idea is that ‘active regions’ implies at a given time. It could only be the entire media context if the regions were active for the entire media context, (and the constraint would then apply for all that time).
I think Mikes objection was that ‘a given time’ is not well defined. It would probably be better if it was something along the lines of
No more than four lines of text must be selected into all active regions in any synchronic intermediate document,

If you have better wording please suggest.

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 12 November 2012 09:24
To: Monica Martin (MS OPEN TECH)
Cc: Timed Text Working Group; Michael A Dolan (mdolan@newtbt.com); Sean Hayes
Subject: Re: ISSUE-180: regions relative to the root container [DFXP 1.0]

On Wed, Oct 17, 2012 at 10:12 PM, Monica Martin (MS OPEN TECH) <momartin@microsoft.com<mailto:momartin@microsoft.com>> wrote:
For Action-105 for SDP-US, propose to revise R0040 and add a new requirement:

1. Change R0040:
Change from: No more than four lines of text must be selected into all active regions at any given time.
Change to: No more than four visible lines of text must be selected into all active regions.

Note: We had previously agreed to delete "at any given time."

Without the "at any given time" the constraint is not well defined, since it could mean "selected into all active regions over the entire external time interval", which I think is not the intended meaning.

2. Add a new requirement to replace one deleted: R0020 in Section 6.4.2:
Origin and extent of a region MUST be authored not to extend outside of the root container.


-----Original Message-----
From: Timed Text Working Group Issue Tracker [mailto:sysbot+tracker@w3.org<mailto:sysbot%2Btracker@w3.org>]
Sent: Friday, September 07, 2012 10:46 AM
To: public-tt@w3.org<mailto:public-tt@w3.org>
Subject: ISSUE-180: regions relative to the root container [DFXP 1.0]

ISSUE-180: regions relative to the root container [DFXP 1.0]


Raised by: Mike Dolan
On product: DFXP 1.0

As currently specified, the values of origin and extent are both unconstrained – they can take any positive or negative number without constraint relative to the root container. But I don’t know what it means to have a region wholly or partially outside the root container, or what to do with negative extent values.  I had always assumed that regions had to be wholly contained within the root container and both origin and extent had to be non-negative. But the spec is not clear to me.

8.2.7 tts:extent says: "...the initial value of the style property [auto] must be considered to be the same as the root container extent." Does this mean that it literally takes the value of the width and height of the root container, or does it mean that it is set to whatever area remains to the right and bottom of the origin contained entirely within the root container?

It additionally says: "If a specified value of this attribute is not supported, then a presentation processor must interpret the attribute as if the value auto were specified." If a region can exceed the area of the root container, then what value(s) are not supported exactly?  It would currently be implementation dependent, and thus could be clipped by a presentation processor to be the root container or not at all or something inbetween.

Whether regions are clipped to be within the root container or not changes the flow behavior considerably (and thus the visible presentation), so leaving it to be implementation dependent seems non-interoperable.

Received on Monday, 12 November 2012 17:38:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:07 UTC