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

Yes. I would expect that the profile/guidelines route would work best. I
think it will be difficult to specify in DFXP a specific minimum range
of Unicode required to be supported by a font.

 

  _____  

From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
Sent: Tuesday, March 29, 2005 6:49 AM
To: Glenn A. Adams
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange
Profile (DFXP) Streaming

 

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 implementation?

 

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)

 

regards 

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

	 

	Glenn,

	 

	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?

	 

	regards 

	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

		Russ,

		 

		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.

		 

		G.

		 

		
  _____  


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

		 

		 

		Russ

			 

		
	
________________________________________________________________________
		This e-mail has been scanned for viruses by MessageLabs.