See below.
_____
From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com]
Sent: Monday, August 11, 2003 12:31 PM
To: Glenn A. Adams
Cc: public-tt@w3.org
Glenn,
<GA>
We would have to extend XPointer to handle ranges that involve words or lines. At present, ranges demarcate their endpoints using character offsets or element offsets, e.g., from 2nd to 4th character, from before element E to after element F, etc.
<JB>
I'm not sure I see that this is a problem - since we wouldn't be using the spans in this instance...
<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.
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
But agreed - this is not quite as elegant as a word / line / character / paragraph selector.
<GA>
Doing a line selector is problematic unless it is based strictly on forced line breaks in content, which would require the authoring system to predetermine line breaks and which would not work well if UA or device could change fonts or layout region. It might be possible to introduce a form of "pseudo" selector that makes selection based on units that are not determinable by lexical content. CSS provides such selectors.
<JB> I'd definitely prefer to avoid hard line breaks - they would tie the content to a specific layout. Within subtitling / captioning, a line break has a greater significance than within 'bulk text' - since there may be an inferred change of speaker etc.....
I think the issues that arise when the "UA or device could change fonts or layout region" are within what I am calling the "temporal flow " model.
That is - I see two distinct modes here:
1) an explicit 'knife and forked' model - where content is without inline **style** markup - but perhaps uses some form of line markup to support selection. This mode is 'author driven' i.e. the author is making choices based on expected delivery interfaces.
GA: Could you explain this "knife and fork" model that you have now referred to a few times? I can guess what you might mean, but I'm would rather you explain.
2) a relaxed model - where content is without **any** inline markup. In this model - the "temporal flow" attributes control how much content is in the region and what happens if it overflows. This supports device independence much more flexibly. So this example might produce pop on subtitles....
<style>
p { display : none; color: blue; temporal-overflow: auto; add-interval: 1s; read-interval: 3s; region-full-clear: all; region-fill-mode: all}
</style>
<cue select="id(p1)" dur="50s"/>
<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>
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.