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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev