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

Re: WebFonts ready for use

From: Patrick Garies <pgaries@fastmail.us>
Date: Wed, 30 Apr 2008 17:31:59 -0500
Message-ID: <4818F35F.7050108@fastmail.us>
To: Maciej Stachowiak <mjs@apple.com>
CC: www-style@w3.org

Maciej Stachowiak wrote:
>  But I think inventing a mechanism for this may be premature
>  optimization. I'd like to see more evidence that font sizes are a
>  major problem compared to other typical web resources, and that this
>  can't be solved in simpler ways (like crunching down the fonts, and I
>  would suggest script-by-script instead of character-by-character for
>  more reusability).

It might help if you could break down a font by Unicode character block 
(which are somewhat along script lines) into multiple fonts and then 
reference these fonts independently for the same Web font. This would 
give authors the flexibility to exercise a lot of control over the fonts 
used for their Web site without sacrificing bandwidth for the download 
of characters in unused blocks or knowing in advance what character 
blocks will be used (e.g., on pages that will accept unfiltered user 
input such as is the case with many forums).

*Example 1*
@font-face {
    font-family: "MyFont";
    src: Basic-Latin, url("MyFont-Basic-Latin.ttf");
    src: IPA-Extensions, url("MyFont-IPA-Extensions.ttf");
    src: CJK-Unified-Ideographs, url("MyFont-CJK-Unified-Ideographs.ttf");
}

The browser would detect whether or not characters from a given block 
were in use and download that block if they were. Fonts associated with 
unused blocks would be ignored. A more powerful mechanism would allow 
one to specify arbitrary blocks of characters to match. Example 2 would 
have an effect identical to Example 1.

*Example 2*
@font-face {
    font-family: "MyFont";
    src: hex-range(0 - 7f), url("MyFont-Basic-Latin.ttf");
    src: hex-range(250 - 2af), url("MyFont-IPA-Extensions.ttf");
    src: hex-range(4e00 - 9fff), url("MyFont-CJK-Unified-Ideographs.ttf");
}

You might also make it so that multiple ranges and/or block names could 
be specified. In Example 3, all of the sub‐examples are equivalent.

*Example 3*
src: Basic-Latin, Latin-Extended-A, url("MyFont-Latin-Basic+Extended 
A.ttf");
src: hex-range(0 - 7f), hex-range(80 - ff), 
url("MyFont-Latin-Basic+Extended A.ttf");
src: hex-range(0 - 7f, 80 - ff), url("MyFont-Latin-Basic+Extended A.ttf");
src: Basic-Latin, hex-range(80 - ff), url("MyFont-Latin-Basic+Extended 
A.ttf");

Examples 2 and 3 could be useful when you only want to use part of a 
block. For example, if you only want to use 1000 characters in a block 
of 5,000 characters, you could either create a font file containing the 
1000 characters alone or merge those characters with the characters of 
another block to create a single font file and match if characters from 
either block are present. Additionally, they would be useful if you 
simply didn’t want to maintain many files or deal with the multiple file 
requests involved (i.e., you might merge multiple whole blocks together).

The values might be more friendly (particularly for referencing multiple 
fonts) if the requests for constants were accepted

*Example 4*
@var { name: "Latin"; value: "Basic-Latin, hex-range(80 - ff)"; }
src: val("Latin"), url("MyFont-Latin-Basic+Extended A.ttf");

— Patrick Garies
Received on Wednesday, 30 April 2008 22:32:40 GMT

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