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

 
Keep in mind that we are creating an authoring format that is intended to meet a variety of needs. This means that we don't have to choose among multiple solutions, but can support many at once. Nobody has proposed that bitmap representations of text be given a preferred status.
 
The TTWG has already identified a requirement to support embedded graphics for icons and other glyphs that aren't available via textual means. The current discussion was prompted by the consideration of whether to support a general mechanism to embed pre-rasterized text for  those environments where delivery is limited to a rasterized form. I can see how it would be an important feature for the author to be able to perform rasterization themselves and to deliver this either by itself or in conjunction with the text that served as input (the latter would be preferred).
 
Regards,
Glenn



  _____  

	From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
	Sent: Monday, May 19, 2003 12:43 PM
	To: public-tt@w3.org
	Cc: shayes@microsoft.com
	
	

	Sean, 

	Comments interspersed: 

	> -----Original Message----- 
	> From: Sean Hayes [mailto:shayes@microsoft.com] 
	> Sent: 16 May 2003 16:12 
	> To: Glenn A. Adams; Johnb@screen.subtitling.com; public-tt@w3.org 
	> Subject: RE: Timed Text (TT) Authoring Format 1.0 Use Cases and 
	> Requirements - Comments! 

	> Bitmaps are also useful to indicate non text (e.g. 'dog 
	> bark', 'music'), 

	How can 'dog bark' be non-text! It quite clearly **is** text. As is the word 'music'. It may not be **spoken** text - dialog in a film say - but it certainly is text.

	There are systems that use bitmaps to carry text content. In some cases this is because of the non availability of a text glyph suitable for the purpose (e.g. musical note) or because the emphasis required for the content, e.g. colours or style is unavailable to a text representation. In other cases it may be because of a desire to 'fix' the presentation style so that the viewer cannot alter it. However, I would strongly suggest that where it is possible to do so - text is always represented as text - not in a pre-rendered form. For what reason? Simply because in some cases the display of the text content to the user may be via non-visual means (i.e. by computer speaking, Braille etc.) In those circumstances the presence of what is basically text content (and in your examples - content intended for deaf viewers) as bitmaps - renders that content unavailable.

	Sorry to hammer this point - but I think it important.... There are IMHO few sound reasons for preferring a bitmap representation over a text one.

	Some examples where a bitmap **may** be prefered over text: 

	Company logos (but should be accompanied by text description). 
	Unique or special symbols e.g. musical notes on a stave (again should be accompanied by text description). 

	I might question as to whether these elements should be capable of being carried in a TTAF file at all. 

	> in these cases it would also be wise to 
	> include an "alt" text, but in such cases the graphic is 
	> probably the preferred rendering. 

	Why? 

	Some good reasons why it might not be. 
	a) User display is different resolution to anticipated. 
	b) User display is different aspect ratio to anticipated. 
	c) User display does not have the colour depth anticipated. 
	d) User display does not have the capability to overlay bitmap data. (e.g. Braille display) 

	> 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. 

	Hmmm....  SMIL customTestAttributes anyone....   ;-) 


	regards John Birch.