W3C home > Mailing lists > Public > public-tt@w3.org > March 2005

RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming

From: <Johnb@screen.subtitling.com>
Date: Tue, 29 Mar 2005 12:48:38 +0100
Message-ID: <11E58A66B922D511AFB600A0244A722EE57DAD@NTMAIL>
To: gadams@xfsi.com
Cc: public-tt@w3.org
Hi Glenn,
So - if a proposed system was to use DFXP as an internal format for data
carriage, and it was considered necessary to make a strong statement about
which codepoints must be supported by any user agent for that system
implementation - then that statement should be made in either a profile for
DFXP or in any guidelines that support/specify the system or UA
E.g A statement could be made defining the ranges of Unicode codepoints that
a UA must support (even if only in a default font)
John B.

-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 29 March 2005 12:18
To: Johnb@screen.subtitling.com
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange
Profile (DFXP) Streaming

DFXP does not define a user agent per se, although it does define the
semantics of presentation processing (Section 3.2, item 5), which in turn is
based upon XSL FO formatting semantics. The issue of whether a glyph is
present or absent in a specified font is user agent dependent, as is whether
the font is present or not. There are also many other aspects of support for
rendering of Unicode text that are user agent dependent, such as: whether
Unicode bidi algorithm is supported, whether the more complex scripts (e.g.,
Indic, Tibetan, Mongolian, etc.) are supported. More particularly, I would
expect a UA to make claims or statements about its compliance with various
conformance criteria established by [1], such as C002 and C003.


[1] http://www.w3.org/TR/2005/REC-charmod-20050215/





From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
Sent: Tuesday, March 29, 2005 4:00 AM
To: Glenn A. Adams
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (DFXP) Streaming




This concept - that DFXP is completely self contained - raises an
interesting point.


Where does DFXP stand on the issue of fonts? Given that DFXP is Unicode -
and thus can contain an extremely wide range of codepoint references - and
the DFXP uses fonts by selection via an attribute set, what is the view
regarding codepoints that are not existent in a referenced font.


Further, doesn't the non-inclusion of the 'font' - or reference to a
standard (by which I mean specified coverage) font... break this 'self
containment' concept?



John Birch.

-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 26 March 2005 05:52
To: Russ Wood
Cc: public-tt@w3.org; Johnb@screen.subtitling.com; shayes@microsoft.com
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (DFXP) Streaming



I'm not exactly sure what you mean by "a DFXP preload and store operation on
first transmission", but I gather that you are generally supportive of not
having references in DFXP to other resources. Correct?


To follow up on your comment about obsolescence of referenced content, it
was indeed an implicit requirement of DFXP that it should be completely
self-contained, just like a video or audio stream or clip.





From: Russ Wood [mailto:russ.wood@softel.co.uk] 
Sent: Monday, March 21, 2005 10:30 AM
To: Glenn A. Adams; Johnb@screen.subtitling.com; shayes@microsoft.com
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (DFXP) Streaming


BULK OF MESSAGE DELETED see comment RW> below


"does not require dereferencing (and subsequent loading) of any resources
other than DFXP content (i.e., no embedded URIs);"

Is this just a timeliness issue?


[GA] No. Having to load any other resource may preclude direct streaming
through inline insertion, otherwise, any referenced resources would have to
be inlined and made availabe contemporaneously.


 Loading of a resource (referred to for example by a header section) would
presumably just delay the ability to decode subsequent timed fragments. A
stream decoder may then incur a 'one off' setup period where referenced
resources were dereferenced and loaded. Any timed fragment in a streaming
scenario would need to be sent some (short) time in advance of its
activation period(s) on the timebase.



RW> Another reason why the referencing of non-included resources should be
prevented is the issue of obsolescence.  If a broadcaster purchases a
programme with subtitles, he wants to know that those subtitles will work
today, tomorrow, next year and in a decade.  If a reference is made to a URI
that needs to be fetched then that resource may have moved for reasons
beyond the control of the originator.


I would prefer not to have a DFXP preload and store operation on first





This e-mail has been scanned for viruses by MessageLabs.
Received on Tuesday, 29 March 2005 11:32:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:01 UTC