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

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.