[webkit-dev] Frustrations with WebKit Font Representation

[Brent Fulgham]

Recently, an update that attempted to share more Cairo-related font
code was added to the WebKit repository
(http://trac.webkit.org/changeset/55510).  While this was no doubt of
great benefit to the Gtk-based ports, it had the unintended side
effect of breaking the WinCairo port, as it placed a
"FontPlatformData.h" file (which had previously been hidden in a
platform-specific gtk directory) into the Cairo directory.  This file
was set up to support Pango or FreeType as rendering backends, and so
failed when attempting to build using the WinCairo GDI-based backend.

My initial thought was to simply copy the salient elements from the
win/FontPlatformData.h file (shared between the Windows CG-based and
Cairo-based builds) into the new cairo/FontPlatformData.h.  However,
this will probably make it easier for the CG port to drift out of sync
with the WinCairo port, creating maintenance difficulty.  After all, I
mostly want to replicate the way Apple's CG port works with fonts, the
only fundamental difference being that WinCairo performs rendering of
the GDI fonts via the Cairo library, while Apple's CG port naturally
uses the CoreGraphics library for its drawing.

After discussing the issue with Adam Roben for a bit, he made the
excellent observation that the main problem was that the
FontPlatformData type was providing the wrong layer of abstraction.
It has morphed into an object type that attempts to encapsulate both
the underlying operating system's concept of a font/glyph (e.g., GDI,
FreeType, Pango, etc.) and the mechanism used to render the font to
screen (e.g., Cairo, CoreGraphics, Skia, etc.).  The various ports
have managed to cobble together a system that works, but in the
process have created a Byzantine structure full of duplicated file
names (FontPlatformData.h, FontCustomPlatformData.h, etc. for each
platform) that generally expose incompatible API's and data
structures.

Based on the existing implementation, I wonder if a better approach
might be possible that would separate the rendering process from the
underlying font representation.  That way, a Windows application using
GDI fonts with a cairo rendering layer could largely share the same
underlying font representation with a CoreGraphics.  Similarly, all
ports built on top of Cairo could use different font representations
(e.g., GDI, Pango, FreeType) but still pipe the drawing logic through
the Cairo layer.

Has anyone else run into these kinds of issues, and might have some
suggestions for how to better approach this problem?

Thanks,

-Brent