Re[3]: updated timed-text document

On Wednesday, 13 March, 2002, 18:09:45, Dave wrote:

> Chris wrote
>>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> I think we are in agreement here.

OK. It also answers the next question:

DS> No dispute on what you wrote here.  The questions that need 
DS> specification concern such considerations as font coverage and style 
DS> coverage.  For example, say I ask for "Times-Roman" and then set a 
DS> Unicode character from an Asian area, and my Times-Roman doesn't have 
DS> Asian glyphs.

Yes. See the algorithm above, loosely paraphrased from the CSS2
specification. So you set "font-family: 'Times New Roman'" and thus
the implementation is allowed to use any fallback font you wish,.
Similarly if you wrote "font-family: 'Times New Roman', serif" it
should first attempt to display characters outside the glyph coverage
of your Times New Roman from whatever font is set up as the serif
fallback; failing that, from any font it wishes.

In fact, this mechanism is frequently used because the latin glyphs in
some wide coverage fonts are not the most attractive ands so a
well-designed, but small coverage, font is placed first in the list,
then a wider coverage font, then serif or sans-serif.


DS>  The 3G spec says that the terminal must render the
DS> glyph if it has it in any font, and that the font substitution 
DS> essentially has to be on a character by character basis.

Good, though it could say it by reference to the CSS2 spec.

DS>  The same 
DS> applies to styles -- Asian fonts and symbols tend to come in far 
DS> fewer weights and display styles than Roman fonts.

Again, what to do if someone asks for five different weights and you
have two, or one, is fully defined in the CSS specification.

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

OK.

>>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> This is a nice analysis and seems like an excellent start.

To clarify - does that mean that you agree with my recommendation, or
that you agree that this is the list and have a different preference
(in which case, what is it?)



-- 
 Chris                            mailto:chris@w3.org

Received on Wednesday, 13 March 2002 13:13:38 UTC