Bug 10691 - WebKit text system needs support for non-system FontData providers
Summary: WebKit text system needs support for non-system FontData providers
Status: RESOLVED DUPLICATE of bug 10649
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P4 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 10649
  Show dependency treegraph
 
Reported: 2006-09-02 03:24 PDT by Eric Seidel (no email)
Modified: 2007-12-29 10:16 PST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2006-09-02 03:24:20 PDT
WebKit text system needs support for non-system FontData providers

Hyatt and I have been talking about this extensively over the last week.  The text system in WebKit will need to be extended slightly in order to support WebFonts and SVG Fonts.

Our current proposed implementation works something like this:

1.  We add an abstract base-class which looks something like this:
class FontDataProvider {
   virtual FontData* fontData() = 0;
};

this base-class is inherited from by anything that can provide a FontData object.  Right now, that's all done by system-specific classes (such as FontCache).

2.  A FontDataProvider would be created based off of the FontDescription and passed to the FontFamliy during creation:

FontFamily(FontDataProvider*)

3.  There could be several different FontDataProvider subclasses.  Examples:

CachedFont : public CachedObject, public FontDataProvider

SVGFontElement : public SVGStyledElement, public FontDataProvider

OSBasedProvider : public FontDataProvider  // obviously this would have a different name

4.  FontDataProviders would either return the FontData object immediately, or would schedule the necessary loads, etc. and then after the load be able to invalidate the document such as to cause a re-layout with the new font data.

5.  Font-fallback would need to be educated such that any FontDataProvider which returned 0 for it's font-data, would simply be skipped.

6.  Due to the way that @font-face is specified, any non-system provider would need to give the system a "first-shot" at finding the font before doing any custom lookup.

7.  Ideally this would be implemented as a first-pass w/o affecting any existing system lookup code.  Meaning that OS-specific lookup would not be done via a FontDataProvider interface, but rather special-cased.  (In fact this might be the best way in the end anyway, since system-lookup always needs to have the "first crack" at resolving a font...)

This is just the current "best guess" implementation design.  But Hyatt and I both seem to agree that this is a feasible approach.  Comments are most certainly welcome.
Comment 1 mitz 2006-09-02 04:45:40 PDT
I would like to know where the current FontCahce fits in under this proposal: is it going to become one of the FontDataProviders or is it going to stay as a layer above them? I think Eric has a reply to that which he's going to add here :)
Comment 2 Eric Seidel (no email) 2006-09-03 23:16:57 PDT
(In reply to comment #1)
> I would like to know where the current FontCahce fits in under this proposal:
> is it going to become one of the FontDataProviders or is it going to stay as a
> layer above them? I think Eric has a reply to that which he's going to add here
> :)
> 

With regards to the current FontCache, Hyatt and I talked about keeping it as a layer above any of the FontDataProviders, but adding a "URL" or some sort of scoping information.  That way system fonts can be long-lived in the cache, document-specific fonts can be purged at the end of a document's lifetime, and also one document would not interfere with any other.  This could also be accomplished by having a separate cache on the document.

Also, I've gone back and re-read how WebFonts are supposed to work.  I was initially confused.  I thought that a single style would reference a particular font by URL (such as font: url("foo.svg")).  This is no the case.  Instead a @font-face definition (or in SVG a <font-face> element) describes a font to be added to the "pool" of selectable fonts.  This font is generally given a name.  It is through this name that the font is later referenced.  For example, if our @font-face declaration gave our font the name "Foo Font" (and referenced foo.svg), then later styles might use "font: Foo Font, Times, serif;" to use this font.  This changes the architecture slightly.  Instead of needing the FontFamily to hold a pointer to the dataprovider as I initially thought, instead the @font-face or <font-face> elements need a way to register themselves and their info for font fallback.  I've not yet read enough about how font fallback works in our engine to comment on how this might be accomplished.
Comment 3 Dave Hyatt 2006-09-03 23:18:36 PDT
See some of the recent www-style@w3.org threads on this.  A lot of browser vendors (including myself and Hakon from Opera) have major issues with @font-face, and don't really think it should be implemented as specified.
Comment 4 Eric Seidel (no email) 2007-12-29 10:16:34 PST
WildFox has implemented an alternative system as part of bug 10649.

*** This bug has been marked as a duplicate of 10649 ***