W3C home > Mailing lists > Public > www-style@w3.org > April 2003

Re: Fonts and character matching

From: Chris Lilley <chris@w3.org>
Date: Wed, 9 Apr 2003 04:28:25 +0200
Message-ID: <14932267718.20030409042825@w3.org>
To: "Ernest Cline" <ernestcline@mindspring.com>
CC: www-style@w3.org

On Tuesday, April 8, 2003, 9:06:37 PM, Ernest wrote:


EC> Right now, the standard calls for determining whether a given piece of 
EC> text can be rendered in a given font on a per character basis. This is 
EC> a reasonable default behavior, but there are times when another 
EC> behavior might be desired.

EC> The following example is very contrived so that I only have to write 
EC> one character reference in my example, but suppose that we have the  
EC> following HTML fragment:
EC>   <q>Come on, Tonto.<br>Hi&#x2010;ho, Silver!<br>Away&#x203C;</q>
EC> where the calculated style rule for font-family is:
EC>   HexCalc, FancyCap, LatinaUno, Unicodia
EC> Now suppose HexCalc only contains glyphs for 0-9, a-f, and A-F,
EC> Fancy Cap contains A-Z and various punctiation characters including
EC> ' ', '.', '!', '-', '!!', and the quote marks,
EC> LatinaUno has glyphs only for the Latin1 character set,
EC> and Unicodia has glyphs for everything in Unicode 3.2.
EC> The current rules call for different parts of the text to be rendered 
EC> in three different fonts despite the presence of a fourth font that 
EC> could display all of the characters.

Yes, because that is exactly what the stylesheet designer asked for.

If they wanted it the other way round then Unicodia by itself would
have sufficed.

The most common use case is placing a font that has nice latin glyphs
ahead of one that has good and complete kanji glyphs but whose latin
glyphs suck.

Use of the unicode coverage descriptor can fine tune this behavior.


-- 
 Chris                            mailto:chris@w3.org
Received on Tuesday, 8 April 2003 22:28:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:20 GMT