- From: Chris Lilley <chris@w3.org>
- Date: Wed, 13 Mar 2002 13:38:21 +0100
- To: Dave Singer <singer@apple.com>
- CC: geoff freed <geoff_freed@wgbh.org>, www-tt-tf@w3.org, w3c-wai-pf@w3.org
On Tuesday, 12 March, 2002, 20:36:16, Dave wrote: DS> At 10:45 -0500 3/11/02, geoff freed wrote: >>Everyone: >> >>The timed-text requirements document has been updated; the new >>version is available at >> >>http://www.w3.org/AudioVideo/timetext.html >> DS> Hi Geoff, some brief comments: DS> a) I'm not sure what the opposition to fonts is; what we said in DS> 3GPP was that the font request was a comma-separated list of DS> "suggestions", which might include the "meta-names" serif, DS> sans-serif, and monospace. Why would you use a different mechanism to the CSS2 font mechanism, which - as you say - gives a list of fonts which are tried in order and then at the end, a genericv font family (serif, etc) which is not a real font name but is a hint, any suitable font can be used, as a last attempt to present the characters in soomething like the desired style, before falling off the end of the list and using *any* font the implementation wishes (which may include displaying some characters as the "missing glyph".. DS> The interaction of fonts, styles, and DS> character sets needs careful exploration. With respect, it does not need careful exploration. There are already well understood mechanisms for how styling applies fonts to a wide range of characters and how character sets 9used for encoding a document in transit) relate to the universal character set (Unicode) which is the conceptual basis on which W3C specifications are built (eg in XML, a numeric character reference always refers to the Unicode code point, never to a byte value in the current encoding). DS> b) I'm not sure what point (2) "usable in all character sets" means? DS> Does this mean "allow all Unicode characters"? I hope that what it means is that Unicode is the conceptual basis, that other encoding can be used but might not be supported by all applications, and that (since this format will have an XML representation) UTF-8 and UTF-16 are supported by all implementations (as required by XML 1.0). DS> c) 3 says to have a default Unicode font, but Unicode isn't a font at DS> all. I'm a little lost here. I think this requirement, taken together with the preceding one are trying to express different aspects of the same thing and should be coalesced. You are quite correct that fonts, already addressed in requirement I1, are orthogonal to the issue. DS> d) Adding the URL <http://www.w3.org/TR/ruby> to point 5 would help. Yes. It would also help if it is made explicit that this markup will be used to add Ruby support, (unless the intention is to design different markup, in which case some justification should be provided). DS> e) Point 6 should say "markup OF the language", i.e. identify the DS> language the text is in. This is needed for text-to-speech, sorting, DS> and various other operations. Yes, agreed. DS> f) 9 asks for motion, right, and IV.1 says no motion. I'd say that DS> "marquee" and "credits" are both pretty key requirements. DS> g) 10 appears to be asking for custom or non unicode glyphs. I guess DS> a major question is whether we use only Unicode as an encoding DS> standard. Unicode is not an encoding standard (though UTF-8 and UTF-16 are encodings of Unicode). Unicode is a universal character repertoire and ordering. Once this point is clear, issues of encoding can be cleanly separated from the basic architecture. Once that is done, there are two possibilities for representing characters not in Unnicode a) the unicode private use area b) the altglyph mechanism, where a font contains glyphs that are not associated with any Unicode code point, but only indirectly (such as by direct id reference, by complex glyph substitution mechanisms for certain languages such as the north indic languages, etc). DS> h) III.2 should probably say "Have a valid XML representation" as we DS> may want to permit compact binary format(s) (e.g. in an RTP packet) DS> as well. I think there are several possibilities, some which this point might be trying to say: a) there will be an XML representation of the timed text format (since markup is mentioned, this is pretty much a given) b) the XML will be well formed (otherwise it is not XML) c) the XML will be valid to a DTD d) the XML will be valid to a W3C XML Schema e) the XML will meet some other validity constraint mentioned in the prose of the specification f) XML will be the only representation of this format g) XML will be the canonical representation of this format, but transcoding to binary XML representations is allowed for particular devices h) there will be a single defined binary representation as well as the XML representation i) there will be many representations, XML is just an example My recommendation would be to select a, b, d, g and consider h and avoid i DS> In general, the document desperately needs a paragraph or two on the DS> usage modes and expected needs, for example: DS> sub-titling DS> karaoke DS> credits DS> ticker tapes DS> closed captioning DS> text overlay DS> hyperlinks and interactivity DS> type-in (user-edited text)??? I agree that some initial expository material justifying why this format is needed and what its intended usage would be, would be a great help once this document comes under wider review. -- Chris mailto:chris@w3.org
Received on Wednesday, 13 March 2002 07:40:12 UTC