RE: Timed Text (TT) Authoring Format 1.0 Use Cases and Requirements - Comments!

One comment:
 
Bitmaps are also useful to indicate non text (e.g. 'dog bark', 'music'), in these cases it would also be wise to include an "alt" text, but in such cases the graphic is probably the preferred rendering. We have had a few discussions on which should be considered the primary rendering, and which a secondary. It is probable that TT will have some author mechanism for expressing a preference order, which can be overridden if it doesn't fit the capabilities of the end user.

________________________________

From: public-tt-request@w3.org on behalf of Glenn A. Adams
Sent: Fri 16/05/2003 14:34
To: Johnb@screen.subtitling.com; public-tt@w3.org
Subject: RE: Timed Text (TT) Authoring Format 1.0 Use Cases and Requirements - Comments!


Thanks for your comments! I have a few responses/comments below inline.
 
G.



________________________________

	From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
	Sent: Friday, May 16, 2003 5:35 AM
	To: public-tt@w3.org
	
	

	Dear TTWG, 
	I have just read the draft document Timed Text (TT) Authoring Format 1.0 Use Cases and Requirements - very clear and comprehensive.

	Please find below some comments. 
	Note in all my comments you may freely substitute caption* for subtitl*  !   :-) 

	RE: Issue (I002): 
	>Should block level graphics be supported, e.g., to permit pre-rasterization of entire lines or blocks of lines of text to serve as alternate content? For example, some subtitling systems use pre-rasterized text that are represented as bitmap graphics.

	It is certainly true that **some** subtitling systems use pre-rasterised text. This is recognised within subtitling as having distinct disadvantages/advantages:

	A: Self-evidently pre-rasterised text precludes the ability to **easily** modify and qualify subtitle files after they have been produced by the subtitler.

	B: Pre-rasterised text requires a greater bandwidth/storage capacity than existing file formats used to code subtitles. 
	C: Pre-rasterised text does not scale well. 
	D: Pre-rasterised text imposes 'producer' choices on the 'consumer' - this may contradict with the required 'house styles' used by consumer.

	There are some advantages: (some of which perversely are the inverse of the above) 
	A: Pre-rasterised text imposes a certain protection on subtitle files, potentially requiring that changes are performed only by a suitably equipped subtitler.

	B: Pre-rasterised text may be previewed by a more simple common viewer agent. 
	C: Pre-rasterised text may allow for more sophisticated text effects and styles that cannot be easily produced 'in real time' at a later stage in the subtitling chain. E.g. 3D glyphs, metallic surfaces and textures...

	D: Pre-rasterised text avoids the 'consumer' detrimentally altering the subtitles (e.g. by selecting too large or small a font) - there is a clear responsibility for poor subtitles.

	While I would not advocate excluding pre-rasterised text - I would advocate that pre-rasterised text ONLY occurs in a TTAF together with a non pre-rasterised form. Further I do not like the term alternate content - as to me it implies that the pre-rasterised form is the 'second' choice - this may not be the intention of the author / user. Surely pre-rasterised text is still text? 

	The idea here was to have an ability to author TT content with pre-rasterized text in addition to the non-rasterized text. I would agree that if we allow pre-rasterized text, then we should mandate the presence of the non-rastserized form as well.

	Regarding the question "[is] pre-rasterized text still text?", I'm not sure it matters how we characterize it. I can see effective arguments both for and against it being characterized as text in a rasterized form. 

	RE: R502 - Highlight Animation: 
	>The TT AF shall be capable of expressing animated highlighting of content, with granularity at the level of individual characters or glyphs.

	The list of animated style parameters is some what restrictive IMHO - being limited to colour changes, visibility and position. Certainly for Karaoke I would suggest that the ability to decorate text (by underline - floating dot etc) might be desirable. Other desirable possibilities for highlighting might include changes to text emphasis (e.g. bold) or even font style / family. One characteristic of highlighting is that it should not IMHO alter the text flow, that is any highlighting of text content should not affect the position of **any** currently displayed glyphs during highlighting. 

	It remains an open question as to whether to permit animation that would cause reflow. Animation of boldness would cause reflow since it changes font metrics; however, animation of underlining and other similar decorations probably would not cause reflow (if specified carefully). Please feel free to propose additions of new properties for which animation should be permitted, and identify whether reflow would be required or not for such animation. 

	RE: Issue (I005): 
	>The rights (accessrights) metadata item defined by [DCMES 1.1] <http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030515/> has not been included here, pending further consideration of whether and what intellectual property rights management (IPRM) related metadata to explicitly support in the TT AF.

	The inclusion of some form of rights and accessrights information is IMHO very important. Also of concern is the need to protect the intellectual property of the content. Speaking only wrt subtitle files - these are costly to produce - and many users regard a subtitle file as a significant asset. The inclusion of rights metadata does not protect the content from unscrupulous exploitation. Is there a means by which the content of the file (by which I mean the Timing / Style and Text) might be encrypted - whilst leaving the metadata in the clear? 

	Please propoes specific meta data items and their value syntax and semantics to serve the needs you feel are important.

Received on Friday, 16 May 2003 12:15:42 UTC