[Webkit-unassigned] [Bug 10691] New: WebKit text system needs support for non-system FontData providers

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=10691

           Summary: WebKit text system needs support for non-system FontData
                    providers
           Product: WebKit
           Version: 420+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: NEW
          Severity: normal
          Priority: P4
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at opendarwin.org
        ReportedBy: macdome at opendarwin.org
                CC: hyatt at apple.com, mjs at apple.com, darin at apple.com,
                    opendarwin.org at mitzpettel.com
OtherBugsDependingO 10649
             nThis:


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.


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.