[Webkit-unassigned] [Bug 55981] New: Clean Up FontPlatformData Structure and Handling

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=55981

           Summary: Clean Up FontPlatformData Structure and Handling
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: bfulgham at webkit.org


The existing FontPlatformData class is overly complicated.  Each port has its own (often incompatible) version, with inconsistent members and life cycle.

In fact, as Adam Roben pointed out previously, the main problem is that the FontPlatformData type provides 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.

This proposed change would separate the rendering process from the underlying font representation.  A Windows application using GDI fonts with a cairo rendering layer should largely share the same underlying font representation as 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 rendering layer.

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