- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 22 Jul 2009 12:03:39 +0200
- To: robert@ocallahan.org
- Cc: "public-html@w3.org" <public-html@w3.org>
On Tue, 21 Jul 2009 11:42:42 +0200, Robert O'Callahan <robert@ocallahan.org> wrote: > On Tue, Jul 21, 2009 at 8:04 PM, Simon Pieters <simonp@opera.com> wrote: > >> For an interactive game, it seems more useful to show the fallback font >> than no text at all, which rules out throwing. >> >> For a static graph, you would either want to draw twice: once with the >> fallback font, and once again when the font has loaded; or you would >> want to >> draw once when the font has loaded. >> >> In order for a Web page to know when a font has loaded, we probably >> need to >> introduce an event that is fired when a web font has loaded, or make web >> font loading delay the load event, or both. >> > > In Gecko, font loads delay the load event. It turns out they do in Opera as well. > However, only font loads that are > actually needed delay the load event. If you set up a @font-face rule but > don't actually use that family (or the family would only be used for > fallback, and fallback is not triggered), then the load event is not > delayed. I haven't tested but I suspect the same would happen in Opera. > I think that drawing text to the canvas that uses a not-fully-loaded font > should actually throw, so script can detect it. I guess we could do that. The script could still draw with a fallback font by setting .font to a different value. I think this needs to hook into the algorithm for strokeText() and fillText() (throwing and causing the font to start to load if it isn't already being loaded). > When the font is fully > loaded then a "fontloaded" event should fire at the canvas, so script can > redraw the text. I guess causing the event to be fired at the right element is also something that the above-mentioned algorithm needs to cover. -- Simon Pieters Opera Software
Received on Wednesday, 22 July 2009 10:04:22 UTC