Re: proposal to replace dynamicFlow

inline

On 1/29/09 11:20 PM, "Geoff Freed" <geoff_freed@wgbh.org> wrote:

> 
> thanks for the response‹ my comments below.
> g.
> 
> 
> On 1/28/09 9:16 PM, "Glenn A. Adams" <gadams@xfsi.com> wrote:
> 
>> 
>> If I undersand this proposal correctly, it is equivalent to:
>> 
>> tts:dynamicFlow=²in(line,jump) out(line,smooth) intra(2.31)²
>> 
>> which says:
>> 
>> (1) to jump scroll in one line at a time, at a auto determined rate;
>> (2) to smooth scroll out one line at a time, at a rate of 2.31 lines per
>> second, which works out to ~0.433sec on screen time;
>> 
>> The way we envisioned controlling the max number of lines (or glyphs) was to
>> define the extent of the region in cell units in order to yield a fixed
>> number of rows (for a font that was sized at 1c). So, the example given below
>> could be expressed now as follows:
>> 
>> <region>
>> <style tts:fontSize=²1c²/>
>> <style tts:extent=²24c 3c²/> <!-- define size of region to be 24 cells wide,
>> and 3 cells (rows) high -->
>> <style tts:overflow=²scroll²/>
>> <style tts:dynamicFlow=²in(line,jump) out(line,smooth) intra(2.31)²/>
>> </region>
>> 
>> The only thing we don¹t have yet is language that says that <br/> or &#x000A;
>> forces a line scroll in (when space is available).
>> 
>> ======
>> GF:
>> i¹m not sure we can assign a single timing value for all cases:  a two-row
>> roll-up display will require different timing than four-row; if i have an
>> audio-only presentation with a large window containing ten rows, that will be
>> different still.  in that case, we¹d have to supply timing values for 2, 3,
>> 4, 5, etc. rows.  also, i don¹t know if what you describe precludes the use
>> of timed roll-up captions (as i included in my example), but we must have the
>> capability to support timed roll-up captions.  that¹s how many shows are
>> captioned in the US today, and we need to support this for reformats of
>> 608-captioned programming into DFXP.  simply converting these single rows of
>> timed roll-up text into discrete pop-on captions would make them unusable‹
>> they¹d be visible for too short a period, and the constant flashing of text
>> would render them unreadable.
>> ======
>> 
[GA] in order to determine if dynamicFlow already supports these
requirements, i need you to be precisely clear for each of these casees (2,
3, 4, 5, ... rows) what the desired timing behavior is; dynamicFlow allows
explicit and automatic control over both scroll-in (fill) and scroll-out
(clear) events, and permits specifying either the fixed interval (duration)
between events or the event rate in terms of units per second based on the
available space (for fill events) or the available presented content (for
clear events), which in turn is sensitive to the region¹s extent and the
units for fill and clear events; see appendix B.3 for the details; there is
also an ³auto²matic algorithm which is based on the active time intervals of
the content presented in the flowed region and the number of units available
for filling or clearing; if the use of a fixed rate or a fixed duration does
not serve, and if the automatic algorithm doesn¹t correspond to the desired
behavior, then we could define another automatic algorithm that corresponds
to the 608 behavior;
>> 
>> So I oppose the the proposal on the basis that we can already support it
>> (albeit with a minor tweak regarding <br/>). It is better to handling
>> subsetting the usage of dynamicFlow by means of specifying mandatory
>> presentation features versus optional presentation features. Indeed, I have
>> already done just that in the new draft I am preparing which I will publish
>> later today, in which I had already anticipated this need, and had
>> accordingly defined a feature ³#dynamicFlow-teletext² that I mapped to a
>> specific value combination of tts:dynamicFlow that is similar to the above
>> (although I had defined it as ³in(glyph,jump) out(line,smooth)²). We can use
>> this feature definition (with any tweaks we think appropriate) to specify
>> what is mandatory in terms of a presentation processor implementation. Or we
>> can define a different combination, such as ³in(line,jump) out(line,smooth)
>> intra(2.31)² and call it #dynamicFlow-rollup. We could also define a new flow
>> function value, if we like, such as:
>> 
>> tts:dynamicFlow=²roll(3)² where in this case 3 would be a parameter
>> indicating maximum number of line areas generated at one time into the
>> region.
>> 
>> ======
>> GF:
>> i would not be against modifying dynamicFlow as long as we can get useful
>> behavior from it easily.  supplying an attribute with fixed features such as
>> scroll rate and row depth is a good idea, but the timing problem still
>> bothers me.  i¹ll have to ponder this some more.  perhaps fixed timing could
>> be an option as long as we make it clear that it may not be appropriate for
>> all use cases (such as reformats from timed 608 roll-up captions).  but we
>> must support timed roll-up as well.
>> ======
>> 
[GA] my guess is that the dynamicFlow timing parameters allow you to achieve
the timed roll-up, but i don¹t have enough detail from your description to
map it out;
>> 
>> In general, I think we really should keep dynamicFlow because we have a
>> formal semantics model for it that defines its timing and presentation
>> behavior in a way that interoperates with the timing and layout model already
>> defined by DFXP.
>> 
>> The focus of this exercise should not be on eliminating dynamicFlow, but on
>> defining what subset of dynamicFlow is needed for supporting roll up
>> semantics, and on clearly specifying that subset as a specific identifiable
>> feature that can be made mandatory (while other dynamicFlow parameter
>> combinations are made optional).
>> 
>> Also, regarding the proposal, I don¹t understand how the proposed tts:rollUp
>> could be applied to body, div, or p. This style as described is a purely
>> region layout oriented property.
>> 
>> ======
>> GF:
>> i didn¹t do a good job defining how it actually can be used in body, div or
>> p, so i¹ll just state that i want it applicable to these elements.  there are
>> 608-captioned programs that move roll-up captions from, say, rows 14 and 15
>> to rows 12 and 13 to dodge an on-screen graphic, and then move back to rows
>> 14 and 15.  that really can¹t be done easily by limiting dynamicFlow to
>> <region>, true?  and there are endless cases where roll-up captions move from
>> the lower-third to the upper-third and back to dodge on-screen activity.
>> broadcasters are going to want to convert their 608 data to DFXP as is, with
>> zero fuss, and that means they¹ll expect the same visible behavior as they
>> had with 608 captions.  can we give them that if we don¹t allow dynamicFlow
>> to be applied to the content?
>> ======
>> 
[GA] i very much doubt that it will be either necessary or desirable to
apply this to content elements; in fact, i suspect it will completely break
the currently specified timing and and layout semantics model;  as for
moving roll-up captions, you can simply move the region by animating the
tts:origin (and tts:extent if needed), or, if you don¹t want to do that, you
could map distinct copies of the same content to different regions at
different times; if DFXP supports the needed semantics, then i very much
doubt how DFXP accomplishes it; they will use a tool that does the necessary
transformation, so won¹t get involved in the detais;
>> 
>> Glenn
>> 
>> On 1/28/09 9:51 PM, "Geoff Freed" <geoff_freed@wgbh.org> wrote:
>> 
>>> 
>>> Partly in support of Andrew¹s message  at
>>> http://lists.w3.org/Archives/Public/public-tt/2008Dec/0137.html, partly as a
>>> counter-proposal to Sean's proposal at
>>> http://lists.w3.org/Archives/Public/public-tt/2008Dec/0142.html, and partly
>>> as a way to rethink the way DFXP supports pre-produced roll-up
>>> captions/subtitles, I submit the following proposal for the replacement of
>>> dynamicFlow.  This is a base proposal; I expect it to receive a severe
>>> beating and, I hope, many improvements while remaining as simple as
>>> possible.
>>> 
>>> PROPOSAL:  Delete <tts:dynamicFlow> from DFXP.  Replace it with a new
>>> element, <tts:rollUp>, which governs only the behavior of roll-up text.
>>> Other dynamic displays, such as crawls, should be defined separately.
>>> 
>>> Here are the basic properties of <tts:rollUp>:
>>> 
>>> 1.  Has at least two attributes:
>>>     -- enable, with the values "on" and "off". Initial value is "off".
>>>     -- depth, which specifies the maximum number of rows that are displayed
>>> at one time.  Values are any non-negative integer.  Initial value is "3".
>>> 
>>> Andrew's message includes a feature which could be very useful if applied to
>>> <region>:  "Leverage the proposed upperThird/middleThird/lowerThird region
>>> tag to allow for the rollup caption area to be positioned appropriately on
>>> the screen. Software that converts 608/708 captions to timed text can
>>> inspect the line positioning and infer the appropriate screen region."  I'm
>>> not sure how to handle this, however.
>>>     
>>> 2.  Can be applied to <region>, <body>, <div> or <p>.
>>> 
>>> 3.  Has fixed timing and scrolling behavior which emulates that specified in
>>> EIA-608:  "... the text in the top row of the window is erased from memory
>>> and from the display or scrolled off the top of the window. The remaining
>>> rows of text are each rolled up into the next highest row in the window,
>>> leaving the base row blank and ready to accept new text. This roll-up must
>>> appear smooth to the user, and must take no more than 0.433 second to
>>> complete.²   (excerpted from "Closed Caption Decoder Requirements for Analog
>>> Television Receivers"; full doc at
>>> http://edocket.access.gpo.gov/cfr_2005/octqtr/47cfr15.119.htm)
>>> 
>>> 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.
>>> 
>>> 
>>> Example usage:
>>> 
>>> <?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">
>>>   <head>
>>>     <metadata> 
>>>       <ttm:title>Example: rollUp</ttm:title>
>>>       <ttm:desc>xx</ttm:desc>
>>>       <ttm:copyright>xx</ttm:copyright>
>>>     </metadata>
>>>     <layout>
>>>         <region xml:id="r1">
>>>             <style tts:backgroundColor="black"/>
>>>             <style tts:color="white"/>
>>>             <style tts:fontSize="14px"/>
>>>             <style tts:origin="0px 240px"/>
>>>             <style tts:extent="320px 150px"/>
>>>             <style tts:displayAlign="after"/>
>>>             <style tts:rollUp="enable(on) depth(2)"/>
>>>         </region>
>>>     </layout>
>>>   </head>
>>>   <body>
>>>     <div>
>>>           <p region="r1">
>>>             <span begin="00:00:01.00">How doth the little crocodile</span>
>>>             <span begin="00:00:03.00">Improve its shining tail;</span>
>>>               <span begin="00:00:05.00">And pour the waters of the
>>> Nile</span>
>>>               <span begin="00:00:07.00">On every golden scale!</span>
>>>               <span begin="00:00:09.00">How cheerfully he seems to
>>> grin,</span>
>>>               <span begin="00:00:11.00">How neatly spreads his claws,</span>
>>>               <span begin="00:00:13.00">And welcomes little fishes in</span>
>>>               <span begin="00:00:15.00">With gently smiling jaws!</span>
>>>               <span begin="00:00:17.00"><br /></span>
>>>               <span begin="00:00:19.00"><br /></span>
>>>           </p>
>>>     </div>
>>>   </body>
>>> </tt>
>>> 
>>> g.
>>> 
>> 
>