- From: Neil Smith <neil@comatose.freeserve.co.uk>
- Date: Fri, 31 Jan 2003 00:16:46 +0000
- To: public-tt@w3.org
At 09:42 30/01/2003 -0800, Jason Terando wrote: >I'm just joining in, so excuse me for any non-sequiturs, redundant points >or simplistic questions. For a bit of background, we develop a closed >captioning editor that we use to create closed captioning feeds, >subtitling, RealText/SMIL, SAMI and Quicktime text tracks. Aye, me too. > Our application uses XML to persist data, and the TT sounds like it > would be a natural emigration for our app for data storage and transmittal. Same here. >Some devices/applications (consumers?) are going to use formatting >characteristics that other consumers won't. Closed captioning (at least >EIA-608) doesn't really deal with the concepts of fonts, unlike subtitling >and most "Internet media" file formats. As well as defining an XML This is where XSL comes in of course - a generic format supporting translation of essential and optional characteristics of a text stream is exactly where the TT group will be heading. I guess they are at the stage now of RFC from the captioning community. Fonts are going to be an optional component I guess, but CSS is definitely the way to express these characteristics - CSS3 has aural stylesheet support for example, extending 'styles' well beyond what can be rendered visually. Its important to separate content from presentation (as always :-) and so if a generic XML description of streamed text is accomplished, we can convert that to any acceptable text format for a variety of output devices. For example, I have developed an internal XML format which I parse using PHP and / or XSL depending on whether the client or server is doing the work.The output is translated easily to QTText, SAMI, Realtext and accompanying SMIL files (in addition, transcripts, WAP and other formats are possible and planned). Equally, I will be able to use XSL to convert any agreed standard to the internal representation used by my scripts without fuss. Its just important to get all the possible attributes of a text stream represented some way. >schema, it might be useful to establish rules/behaviors that consumers >would abide by if they come across information in a TT file/stream that >they don't process. > >I guess where this is going is should TT files include the ability to >address multiple types of consumers in a single/file stream; or would it >be better from a design, implementation and consumption standpoint to >limit each TT file/stream to a single type of consumer; or to support >heterogenous types of consumers in a single TT file/stream? I think a generic standard containing the essential and optional components of a presentation should be mandated. For example - QTText needs to know the length of a presentation for the final time tag [this is not a requirement for SAMI and RT]. So, this should be included as an optional component of a prerecorded presentation - but how to determine this for an open-ended, live presentation ? SAMI likes its output formatting as CSS, whereas RT likes font size & color tags. Quicktime of course is a law unto itself - and as you say some output formats have no concept of fonts, but the information should be optionally available. The possibility to indicate various formatting styles should be possible per line of captions - emphasis, alignment / positioning, even colour may have their place. We may create a presentation which has banner descriptors for subsections (I think Apple calls this a chapter track). This would be a useful addition, and can be inserted at the start of a 'scene' if the dialogue is otherwise sparse. Sounds optional to me, but a useful consideration. Anyway its late here - will catch more tomorrow (this discussion seems to have taken off :-) Neil Smith. ======================================================= VideoChat with friends online, get Freshly Toasted every day at http://www.fresh-toast.net : NetMeeting solutions for a connected world.
Received on Thursday, 30 January 2003 19:08:07 UTC