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

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

From: Glenn A. Adams <gadams@xfsi.com>
Date: Tue, 29 Mar 2005 06:18:22 -0500
Message-ID: <7249D02C4D2DFD4D80F2E040E8CAF37C0E912D@longxuyen.xfsi.com>
To: <Johnb@screen.subtitling.com>
Cc: <public-tt@w3.org>
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;
	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;
	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 transmission.





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

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