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

Glenn  wrote:
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.

[JB> ] Sorry - I thought that was exactly what Sean was proposing -- "
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."
[Note: I interpreted Seans 'non text' here as meaning non spoken as the
examples given **are** text.]
 
Glenn  wrote:
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).
 
[JB> ] I have to say that I personally find it difficult to conceive of a
scenario where it would be preferable to **only** have pre-rasterised text
in an file intended as an **authoring** format.
 
Both pre-rasterized text bitmaps and character sequences are equally valid
representations of 'text', but the issue is surely one of accessibility and
editability (which must be of paramount concern in an authoring format).
Certainly there are **delivery** formats where 'text' is only carried in
bitmap form (digital video subtitles being one example), but is it valid to
carry the limitations of a delivery format back into the authoring format? A
common justification for pre-rasterised text is that the exact output format
is known (which of course also completely ignores the accessibility issue).
But standards change: the introduction of widescreen and high definition TV
standards has invalidated many pre-rasterised text bitmaps originally
developed for standard definition TV.

I would personally like to see pre-rasterised text content 'allowed' in a
TTAF file **only if** an equivalent character text form of the
pre-rasterised text was strongly recommended to also be included. This
character text form might need to be descriptive where no direct character
equivalent was available. It might be included either as a) metadata for the
pre-rasterised form, or b) an equivalent selected by some external
mechanism.
 
Finally, if bitmap representations of **text** are to be part of a TTAF,
then another issues arises:
Are bitmaps that are definitely "not text" supported? (e.g. pictures) - or
is there a case for allowing bitmaps only as direct text equivalents but not
as images?

Regards,

John Birch. 

  _____  

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