[Webkit-unassigned] [Bug 10649] WebKit SVG needs SVG Fonts support

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=10649


eric at webkit.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mitz at webkit.org,
                   |                            |hyatt at apple.com




------- Comment #2 from eric at webkit.org  2007-10-23 21:37 PDT -------
Ok, now that bug 10652 is in, I'm ready to implement a real SVG fonts system. 
I waded through the WebCore font system today and have come up with something
resembling a plan.

Some background on the CSS @font-face system:
CSSFontFace elements own their CSSFontFaceSource elements, which in turn own a
CachedFont object which does the actual loading.  CSSFontFaceSource elements
provide the actual FontData objects into the font system (FontCache, etc). 
Actual users hold onto Font objects, which build a FontFallbackList object
behind the scenes, and try and grab the fonts in that list from the FontCache
using the FontSelector.  The FontSelector (actually CSSFontSelector) which
holds all the CSSFontFaces under a hash (by family name, weight, etc.) If the
font selector has a CSSFontFace in its cache, it will try and grab the FontData
from that CSSFontFace (which in turn tries to grab it off the
CSSFontFaceSource).  If none of the standard variants for the font
family/weight/etc. are found in the CSSFontSelector's hash, then it gives up,
and the FontCache keeps walking down the FontFamily list (held by the
FontFallbackList).  If none of those return anything, then there is a last
resort font which is pulled from the platform.

So, that's how font lookup works... more or less, as I understand it.

I see SVG hooking into the system by subclassing from CSSFontFaceSource, an
SVGFontFaceSource object, perhaps.  SVGFontFaceSource can handle
loading/storing the font data (local or remote) and create the proper FontData
subclass (SVGFontData) without calling out to any platform code.

The rest of WebCore is only really exposed to the Font object.  This will
remain true in SVG Fonts.

Once a render has a Font object, it will eventually call Font::drawText to do
the drawing.  Font::drawText makes a choice (based on the glyphs) as to which
font path to go down. The "simple" or "complex" path.  SVG would require adding
a 3rd path here.  This 3rd path would look identical to simple text drawing,
except that the drawGlyphs call would use the glyph data out of the SVG font
instead of the platform font data.

Providing advanced functionality for SVG fonts (like cascading style from
current text run onto the actual glyphs) could be done at a later point. 
(This, for example is, how SVG Fonts get coloring -- default fill is black, no
stroke.  But SVG Fonts might come with their own intrinsic colors.  crazy, eh?)


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