W3C home > Mailing lists > Public > public-tt@w3.org > February 2009

Re: timed roll-up captions: sample video and code

From: Glenn A. Adams <gadams@xfsi.com>
Date: Fri, 06 Feb 2009 22:53:13 +0800
To: Geoff Freed <geoff_freed@wgbh.org>, Public TTWG List <public-tt@w3.org>
Message-ID: <C5B26FD9.9162%gadams@xfsi.com>

Iıve taken a look at the demo clip and reviewed your explanation below, as
well as the explanation in [1]. First, I notice that the clip doesnıt
correspond to your explanation in [1], particularly when you said:

> 4. A row of text does not paint horizontally or "unroll" into the region when
> it appears; it simply scrolls up in its entirety.
> 
> 5. The currently displayed bottom row of text need not be full in order to
> force the display to roll up. That is, if the bottom row ends with a linefeed
> or a <br />, the next row will roll up regardless of the length of the current
> row.².

>From the clip, it appears that the bottom row of text is simultaneously
being (1) filled in from left to right and (2) scrolled up as the top line
is being scrolled out. If this is correct, then the following semantics
apply (see note below about the use of ³cell² as a flowUnit):

tts:dynamicFlow=³in(cell,smooth) out(line,smooth)²

*We donıt currently have a flowUnit of ³cell², but it looks like we need
one. Neither character nor glyph correspond to cell, since whitespace does
not (typically) generate glyph areas, and because in some written languages,
characters correspond neither to glyphs nor cells as such.

In contrast, your earlier explanation appeared to correspond to:

tts:dynamicFlow=³in(line,smooth) out(line,smooth)²

i.e., the fill unit was an entire line, and not a cell.

Ignoring this difference in explanation for a moment, and taking the clip as
the intended behavior, the first of the above two uses of dynamicFlow would
apply. The real question is what fill and clear intervals should apply. It
appears to me that what we have here is a case where

(1) the fill interval is auto as described in B.3.1, i.e., the rate at which
cells are filled into the new line is proportional to the length of the line
measure of the region (i.e., its width) and the number of fill units (in
this case, cells), available in the flow buffer to be presented; so, for
example, if the flow buffer contained the content

{text=³steel trees.²,numCells=12,begin=12.15s,dur=2.06s}

Then the computed fill interval would be 2.06s/12cells=0.172s/cell.

(2) it is not clear what the clear interval should be; in particular, I have
heard conflicting explanations: below, and in [1], it is suggested that the
clear interval (for scrolling out a line) should be 0.433s, however, in on
of the previous telecons, someone stated that if text arrived into the flow
buffer at a faster rate, that it would flow out more rapidly; this sounds
more like a combination of semantics such as:

* clear interval is by default 0.433s
* however, if a new line arrives (more precisely, the first cell of a new
line area) arrives, and if the clear interval duration of 0.433s has not
been reached (i.e., the clear timer is active, but not yet fired), then the
clear timer should be fired immediately (causing a new flow out (clear)
operation);

I believe these semantics could be expressed as follows, while introducing a
syntax to express modifiers to a flowIntervalFunction:

tts:dynamicFlow=³in(cell,smooth) out(line,smooth)
inter(433ms,<modifier-token>)²

What I need to ponder further is how to characterize, and thus name a
<modifier-token> that corresponds to this desired behavior. Introducing this
would also require a minor modification to B.5.1 (3).

Regarding your proposal for a ³<608rollUp>² element, there are problems with
this as I indicate inline below.

Glenn

[1] http://lists.w3.org/Archives/Public/public-tt/2009Jan/0030.html

On 2/6/09 1:06 AM, "Geoff Freed" <geoff_freed@wgbh.org> wrote:

> 
> iıve uploaded a 20-second demo clip of pre-timed roll-up captions at
> http://ncamftp.wgbh.org/geoff/tcru2+3_ttwg.mov .  iıve added annotations which
> point out basic features.  the quality is low but youıll get the idea.  note
> the following:
> 
> --  each row of text scrolls in and out smoothly
> --  the appearance of text from left to right is smooth and continuous
> --  the maximum number of rows (three or two), as well as the position of the
> regions, changes on the fly
> 
> below is what brad and i think the caption file for this clip would look like
> using current DFXP markup to emulate EIA-608 behavior.  note that rather than
> create two regions (one for captions in the upper third and one for lower
> third), iıve animated the origin and extent of a single region.
> 

> ============
> <?xml version="1.0" encoding="utf-8"?>
> <tt xml:lang="en"
>     xmlns="http://www.w3.org/2006/10/ttaf1"
>     xmlns:tts="http://www.w3.org/2006/10/ttaf1#style"
>     xmlns:ttm="http://www.w3.org/2006/10/ttaf1#metadata"
>     xmlns:ttp="http://www.w3.org/2006/10/ttaf1#parameter"
>     ttp:cellResolution="32 15">
>   <head>
>     <metadata>
>       <ttm:title>Example: roll-up captions with animated regions</ttm:title>
>       <ttm:desc>xx</ttm:desc>
>       <ttm:copyright>xx</ttm:copyright>
>     </metadata>
>     <layout>
>         <region xml:id="captions">
>             <style tts:backgroundColor="black"/>
>             <style tts:color="white"/>
>             <style tts:fontSize="14px"/>
>             <style tts:origin="1c 1px"/>
>             <style tts:extent="32c 2px"/>
>             <style tts:displayAlign="after"/>
>             <style tts:dynamicFlow="in(line,smooth) out(line,smooth)"/>
>             <set begin="00:00:00.00" end="00:00:14.21" tts:origin="1c 1c"
> tts:extent="32c 2c"/>
>             <set begin="00:00:14.21" end="00:00:19.73" tts:origin="1c 13c"
> tts:extent="32c 3c"/>
>             <set begin="00:00:19.73" end="23:23:59.00"
> tts:visibility="hidden"/>
>         </region>
>     </layout>
>   </head>
> 
>   <body>
>     <div>
>           <p region="captions">
>             <span begin="00:00:09.63">&gt; &gt; JAMIE: Well, this week
> Iım</span>
>             <span begin="00:00:01.58">starting at the Getty Museum</span>
>             <span begin="00:00:02.79">here in Los Angeles, at Robert</span>
>             <span begin="00:00:04.42">Irwinıs famous Central Garden.</span>
>             <span begin="00:00:06.63">And in particular focusing on</span>
>             <span begin="00:00:08.15">these incredible espaliered</span>
>             <span begin="00:00:10.00">bougainvilleas up these manmade</span>
>             <span begin="00:00:12.15">steel trees.</span>
>             <span begin="00:00:14.21">They're made out of steel</span>
>             <span begin="00:00:15.15">reinforcing, and they're just</span>
>             <span begin="00:00:16.42">incredible.</span>
>             <span begin="00:00:17.05">Come on, I'll show you.</span>
>             <span begin="00:00:19.73"><br /></span>
>          </p>
>     </div>
>   </body>
> </tt> 
> 
> ============
> 
> as currently structured, thereıs no way to know by looking at the content area
> that these captions are supposed to be roll-up captions--  for that
> information, you need to look at the layout.  ideally an author ought to be
> able to explicitly state in the content area that a block of text is roll-up
> captions.  in addition (and to follow up on something we discussed on last
> weekıs call), it would be useful to have a tag that contains inherent roll-up
> characteristics which emulate 608 behavior, streamlining the authoring of
> roll-up captions.  letıs say the tag is called <608rollUp> and embodies the
> following fixed behavior:
> 
[GA] I continue to object to the idea of associating rollup semantics with
content as opposed to a layout region. It still does not make any sense to
me (if that is what is meant by ³in the content area² above).
> 
> --  smooth scrolling of rows as they scroll into and out of the region
> <tts:dynamicFlow="in(line,smooth) out(line,smooth)>"
> --  a scrolling speed that corresponds to that specified by EIA-608 (.433
> seconds) 
> --  smooth appearance of characters as they paint in from left to right
> 
[GA] I would not object to defining a shorthand value such as
tts:dynamicFlow=²rollUp², which translates to a fuller specification as
indicated above, namely:

tts:dynamicFlow=³in(cell,smooth) out(line,smooth)
inter(433ms,<modifier-token>)²

> 
> -- a safe area corresponding to a 5% margin (padding, i suppose...) on all
> four sides
> 
[GA] It may be possible to do this if we allow tts:extent on <tt/> to be
expressed in terms of percentage length values. We donıt permit this at
present.
> 
> -- a 32c x 15c layout (which is DFXPıs current default ttp:cellResolution)
> 
[GA] Since this is already defined as the default, and it can be overridden
by specifying ttp:cellResolution direction, there doesnıt seem to be any
need for something special here.
> 
> -- a region that is black and persistent when it is visible, which differs
> from 608 behavior where the region is transparent and the characters have a
> background color
> 
[GA] Iım not sure what you desire here. Do you want the 608 behavior? The
above example is probably incorrect, since it should specify
tts:backgroundColor=²transparent² on the <region>, but
tts:backgroundColor=²black² on <body> or <p>. You can also use
tts:showBackground on <region> to determine whether its background is
visible in the absence of active content in the region.
> 
> -- a font size which is not specified by the author but is instead determined
> by the user agent, relative to the size of the root container, and which fits
> into th 32c x 15c raster
> 
[GA] I believe this can be specified already with tts:fontSize=²1c² on
<region> or <body>.
> 
> an idea worthy of further discussion?
> 
[GA] There seems to be at least two other problems with the above example:
(1) the durations on <span> elts are missing, and not implied by the start
of the following element (since <p> is timeContainer=²par²), and (2) since
there are no <br/> elements, the forced end of lines shown in the example
clip would not be respected; i.e., the arrival of new content via a
subsequent <span> would simply add content to the end of the current line
without causing a forced line break.
> 
> g.
> 
> 
> 
Received on Friday, 6 February 2009 14:54:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:40 GMT