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

Haven't gone over the draft yet, but wanted to reply to the bitmap topic
raised.

Bitmaps may be preferred on some renderers, but I think it may be
counterproductive to treat the text as "alt" or optional, since many
prevalent renderers (including closed captioning, SAMI and quite a few
subtitling devices I've run across) don't have capability for embedded (or
any) bitmaps.  One constituency we're trying to help with timed *text* can
end up being visually impaired folks who are using Braille readers.  Text is
also nicer if one is going to try and co-opt TT data for indexing/library
purposes.  This isn't to say I'm anti-bitmap or anything, just that there
might be some benefit to keeping the emphasis on text capabilities.
Probably just being paranoid...


> -----Original Message-----
> From: Sean Hayes [mailto:shayes@microsoft.com]
> Sent: Friday, May 16, 2003 9:12 AM
> 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!
> 
> 
> 
> 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.