Re: [public-tt] <none>

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