[webkit-dev] Frustrations with WebKit Font Representation

[Brent Fulgham]

Hi Gustavo,

On Wed, Mar 17, 2010 at 7:22 AM, Gustavo Noronha Silva <gns at gnome.org> wrote:
> While I agree with the rest of your email, I failed to understand the
> actual problem this caused. Is it because the include path for
> platform/graphics/cairo is coming before the one you were using, and
> then picking up the wrong file on include?

Previously, FontPlatformData.h did not exist in the
platform/graphics/cairo folder.  Consequently, the FontPlatformData.h
in the specific port directory (gtk, win, etc.) was always used when
building FontCairo.cpp.  However, by adding a local FontPlatformData.h
to the cairo folder, this file now is preferentially used by the
compiler, since FontCairo.cpp is currently built before the
port-specific files and is in the immediate proximity of the
compilation unit.  gcc might not suffer from this problem, but MSVC
always prefers a filename from the compilation unit's current
directory to something in the search path.  Consequently, changing
order of search paths will not resolve this issue.

So to resolve the build, there are a couple of options:

1.  I can locally delete the
platform/graphics/cairo/FontPlatformData.h, and everything reverts to
a normal build for me.  Obviously this is not viable for a long-term
solution.
2.  We can rename the various FontPlatformData.h (in win, gtk, etc.)
to something like FontPlatformDataWin.h/FontPlatformDataGtk.h, etc.
and use a chromium-like generic FontPlatformData.h that internally
(using various #if/def tests) includes the specific xxxxWin.h,
xxxxGtk.h, etc. needed for the current port.
3.  We can refactor the current font logic to more properly separate
the font representation from rendering engine, as proposed in my last
e-mail.

The quickest way to resolve things is probably #2, but I think #3
might be better for the project.

-Brent