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

Re: Fonts and character matching

From: Ernest Cline <ernestcline@mindspring.com>
Date: Wed, 09 Apr 2003 11:53:55 -0400
To: www-style@w3.org
Message-ID: <3E9409D3.32393.36AF613@localhost>

Chris Lilley wrote:

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

Which stylesheet designer?  The suthor, the user, or an interaction 
between the two?  Consider the following as a possible user stylesheet.

* {font-family:LatinaUno,Unicodia}
:root {font-match:all}  

This would enable users to specify that unless the author has chosen a 
different behavior, they want documents to be displayed all in the same 
font, and that while they prefer the look of LatinaUno, they feel that 
Unicodia has a more complete set of glyphs. This sort of behaviour is 
not currently able to be specified by CSS, as far as I know, but is 
something I can see being useful.  

The example I gave in my first post was intended more to be brief and 
to show off what could be done than to give examples of real world 
usage. Having given a reason why a user might wish to make use of such 
a property, let me give an example of another that shows why an author 
might wish to make use of font-match.  

Unfortunatly, an author cannot be certain that a font which comes in 
several different versions, say perhaps one that has been updated after 
each new Unicode release, will contain the character he wants.  If his 
preference is for the document to use FontA if the user has a version 
of it that has the desired glyph and if not, then try another font, 
with all of a particular section being done in a single font, then font-
match would enable him to do that.

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

What unicode coverage descriptor?  The only thing I could find that 
sounded like this in CSS was in the @font-face rule, and my proposal 
had nothing to do with whether or not a font is downloaded or 
synthesized.  The @font-face rule comes close to doing what I would 
want font-match to do but not quite.  In order to fully substitute for 
font-match, @font-face requires that the writer of the rule have 
perfect knowledge of both the characters available in the font and of 
the characters used by the document.  However, the usual case today is 
that the author supplies the document and the user supplies the fonts.  
Therefore, @font-face simply is not going to work for the purposes that 
font-match was intended to address.  Perhaps a variant on @font-face 
that would require that the font have the characters given by the 
unicode-range and if it did not, then to treat that rule as invalid 
would suffice for author usage of my proposed font-match. say for 
eaxmple something like this:

@font-face {
  font-family:"Font1";
  src:local("FontA");
  unicode-domain:U+0000-U+007F,U+0191-U+0193;
}
@font-face {
  font-family:"Font1";
  src:local("FontB");
  unicode-domain:U+0000-U+007F,U+0191-U+0193;
}
@font-face {
  font-family:"Font1";
  src:local("FontC");
  unicode-domain:U+0000-U+007F,U+0191-U+0193;
}

where unicode-domain, unlike unicode-range would require the listed 
unicode characters to be part of that font, or else the rule would be 
invalid.

Then instead of:

E {font-family:FontA,FontB,FontC;
   font-match:element;}

The usage would be:

E {font-family:Font1,FontA,FontB,FontC;}

Not quite as flexible as font-match, but on the other hand it would be 
a lot less computationally intensive. I can see where it would serve 
any author needs for font matching
Received on Wednesday, 9 April 2003 11:53:37 GMT

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