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?

	 
	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. 

	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. 

	 
	I'm trying to get my head round this - don't want to stray too far from current concepts - but are we jumping through hoops to avoid modifying the style model here?
	
	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.