- From: Jonathan Kew <jfkthame@googlemail.com>
- Date: Fri, 25 May 2012 09:52:00 +0100
- To: www-style@w3.org
On 25/5/12 08:27, John Daggett wrote: > Explicitly loading a font is hard because fonts are loaded based on > the contents of some element that uses a given font family. The style > matching algorithm determines the specific face to be loaded. And > after the font loads *another* font might be needed if a given > character isn't supported by a character within the text run using > that font. Yes, I was going to make a similar comment. We can't tell what resources are needed purely from looking at the style rules. Only running the font-matching algorithm with the exact text content to be rendered will determine which resources need to be downloaded; and as downloads are completed, we may discover that additional resources are needed. (As an aside, Gecko currently gets this wrong; it triggers the load when it sees an element whose font-family property includes the user font as one of its list of families, rather than waiting to see whether the content will actually require this font. I recently filed a bug about this, as it can result in loading resources that are never used, and will become worse when we add unicode-range support.) For use cases such as canvas, it might make sense to have an API that can be used to initiate the loading of *all* resources referenced by a given font-family name and style, independent of matching fonts to specific text content. If an app is intending to accept text from the user, for example, and draw it to a canvas using a (composite, multi-unicode-range) webfont, the only way it could be sure the resources will be available when needed is to load them all eagerly. JK
Received on Friday, 25 May 2012 08:52:42 UTC