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

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.