RE: TT and subtitling/captioning - separating timing from style f rom content

Glenn,
 
my comments below in green

-----Original Message-----
From: Glenn A. Adams [mailto:glenn@xfsi.com]
Sent: 12 August 2003 16:37
To: Johnb@screen.subtitling.com
Cc: public-tt@w3.org
Subject: RE: TT and subtitling/captioning - separating timing from style
from content


 

-----Original Message-----
From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
Sent: Tuesday, August 12, 2003 6:14 AM
To: Glenn A. Adams
Cc: public-tt@w3.org
Subject: RE: TT and subtitling/captioning - separating timing from style
from content


Glenn,
 

<p id="p1">
Scooby dooby doo where are you?
we've got some work to do now
Scooby dooby doo, where are you?
we need some help from you now
come on Scooby doo, I see you
pretending we've got a slither
you're not fooling me, cause I can see
the way you shake and shiver
</p>
 
so presumably:
 
<cue select="#xpointer(p1/range(1.0, 1.31))" use="a2" dur="1"/>

<cue select="#xpointer(p1/range(1.32, 1.61))" use="a2" dur="1"/>

<cue select="#xpointer(p1/range(1.62, 1.91))" use="a2" dur="1"/>
 
and so on
 
 - would select lines from the paragraph.
 
GA: Your example doesn't select lines; rather it selects characters which
may or may not be mapped to a line. Unless you are using manual line breaks,
e.g., by using a <br/> element or a style property equivalent, then
selecting character runs in this fashion would not be guaranteed to map to a
line since you may have font substitutions, different region sizes, etc.
 
<JB>
Well it selects lines from the content - agreed that they may not map to a
line on the display region. I was assuming when I wrote this that there was
a  layout property in style a2 that caused a line break. In some cases (e.g.
snake mode) you would not want a line break. As regards font substitutions
and different region sizes - I see the above example as the explicit model -
i.e. all this is pre-calculated by the author - default overflow mode is
hidden - so superfluous content is clipped from the region (not very
desirable for subtitling / captioning!). 
 

GA: OK, that (a style property) would work. However, since in this scenario
the author is manually selecting line break points irrespective of the
contingincies of user agent display, I can't see a great advantage to using
range selection over explicit markup in content. I suppose your response
would be that by not using markup to delineate lines, that you can apply
multiple timesheets/stylesheets to the same content without changing the
content such that these different timesheets/stylesheets could select
different lines or units. Is this the crux of your argument for using
external ranges rather than inline markup?


[JB> ] Let's say it's one of the supporting arms for my desire to allow
external range based selection cf inline delineation.Certainly within my
area of interest - I would like to be able to have a TT-AF file with a
single content area, that was used by multiple timesheets/stylesheets - for
use when an author has explicitly catered for different presentation
scenarios. I.e. The same file is usable for Teletext, Open, DVB and DVD
presentations (each of which have different timing and style limitations). 

GA: What we would need is effectively a pseudo selector that operates on the
area tree produced by the layout process. The layout of the above paragraph
may produce one or more block areas, each containing one or more line areas,
each containing one or more glyph areas. 
 
Perhaps we can introduce a new axis extension that logically selects areas
produced by formatting the referenced content, e.g.,
 
id('p1')/area::line(1)                  // select first line area
id('p1')/area::line(1)/glyph(1)    // select first glyph area of first line
area
 
<JB>
I'm not really sure I understand how this could work - What in the above
statements defines the style (which specifies the font, region size etc)
that the selection mechanism uses to determine how long the line is?
Especially in the case of style animation..... 
 

GA: I was just providing an example of how by introducing a new axis into
XPath expressions that we could select areas produced by formatting content
as opposed to selecting the content itself. For example, if you wanted to
time the appearance of line areas at authoring time but you don't know where
line breaks will occur (because UA is performing line breaking), then by
using the above mechanism you could associate timing and style properties
with the areas produced by the formatting process. Since XPath only provides
axes that select lexical content, we would need such an extension if we
wanted to time or style the results of formatting. 


[JB> ]  I think I understand the direction you're going in here - but I see
a problem. You have used line numbers in your examples, but the document
author has no a priori knowledge of where the UA will line break - so how
many selectors should he create, 1, 2, 3, (how many lines will the content
be broken into by the UA?). The number of lines the content is broken into
by the UA should affect the timing of those lines......
the two are intrinsically linked - linebreaking in subtitling / captioning
creates potential temporal overflow (the need to remove existing content)
which affects the timing of all the content - including the first displayed
content. 
 
I.e. (not intended to be xml) - the first stanza as three lines, the second
into a two line region.
 
[Example 1 seq end="6s" - three liner]
[dur = "2s"]

Scooby dooby doo where are you?
we've got some work to do now
Scooby dooby doo, where are you?

[dur = "2s"]
we need some help from you now
come on Scooby doo, I see you
pretending we've got a slither
 
[dur = "2s"]
you're not fooling me, cause I can see
the way you shake and shiver

[/seq]



 
[Example 2 seq end="6s" - two liner]
[dur = "1.5s"]

Scooby dooby doo where are you?
we've got some work to do now

[dur = "1.5s"]
Scooby dooby doo, where are you?
we need some help from you now

[dur = "1.5s"]
come on Scooby doo, I see you
pretending we've got a slither
 
[dur = "1.5s"]
you're not fooling me, cause I can see
the way you shake and shiver

[/seq]


I think the insertion of a 'temporal line break' has to be in the style
domain - not in the content domain. If an individual selection defines too
much content for a line (assuming that is the mode of the temporal line
breaking model) - then 'normal' style attributes for overflow (marquee -
scrolling etc) would be applicable. 
 

GA: I don't believe we can force one particular model on all uses. Some
authors may want to express in content domain for whatever reason, others
may want to express in style domain. We should support the vocabulary to
express both models. 


[JB> ] I'm in total agreement - though I personally regard content domain as
strongly associated with the knife and fork - hard layout - explicit styled
document models. As I've said previously - I think that it is currently
possible to imitate existing subtitling authoring formats using standard xml
and CSS style. An added wrinkle is the use of selectors to remove the need
for inline line demarkation and style animation to support ideas like
Karaoke. But I personally don't see much of a unique selling point (USP) in
transferring across to this form of TT-AF from existing file formats (aside
from the use of Unicode).
 
What I'd like to continue to see developing is a vocabulary for soft layout.
Although style animation and enhanced selectors can help - I still feel
there is a need to develop a vocabulary for temporal overflow. The CSS
overflow attributes don't go far enough in controlling how a region is
emptied to make space for new content. Concepts like explicit marquee-speeds
don't work - since you cannot predict the size of the region on the UA that
is being used - the required speed is content / time / region size
dependent. Also missing are many subtleties in how the region is
reused/reflowed. This is where I see the USP.....

regards 
John Birch 

The views and opinions expressed are the author's own and do not necessarily

reflect the views and opinions of Screen Subtitling Systems Limited.