Re[2]: updated timed-text document

Chris

thanks for the thoughtful reply.


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


I think we are in agreement here.

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

No dispute on what you wrote here.  The questions that need 
specification concern such considerations as font coverage and style 
coverage.  For example, say I ask for "Times-Roman" and then set a 
Unicode character from an Asian area, and my Times-Roman doesn't have 
Asian glyphs.  The 3G spec says that the terminal must render the 
glyph if it has it in any font, and that the font substitution 
essentially has to be on a character by character basis.  The same 
applies to styles -- Asian fonts and symbols tend to come in far 
fewer weights and display styles than Roman fonts.

On your follow-up to this, that we should use existing 
well-thought-out practices from other W3 specs., again, no dispute.

>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

This is a nice analysis and seems like an excellent start.


-- 
David Singer
Apple Computer/QuickTime

Received on Wednesday, 13 March 2002 12:18:33 UTC