Re: [webkit-dev] Frustrations with WebKit Font Representation
On Tue, 2010-03-16 at 15:49 -0700, Brent Fulgham wrote: 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 It was really no benefit for GTK+-based ports, this move was made so that other ports (in this case EFL) could use the font implementation that is not tied to GTK+. 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? See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Frustrations with WebKit Font Representation
Hi Gustavo, On Wed, Mar 17, 2010 at 7:22 AM, Gustavo Noronha Silva g...@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 Win.h, Gtk.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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Frustrations with WebKit Font Representation
I'd say for our configuration that uses wince/cairo and rendering with freetype that this is a welcome move as we've been working with this font configuration between cairo and windows CE and copying the gtk code over manually for now to get it working. I haven't yet integrated this change into our tree though so I'll wait and see what happens when we have to do that. -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Brent Fulgham Sent: Tuesday, March 16, 2010 3:50 PM To: Webkit Development List Subject: [webkit-dev] Frustrations with WebKit Font Representation 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Frustrations with WebKit Font Representation
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
Re: [webkit-dev] Frustrations with WebKit Font Representation
On Tue, Mar 16, 2010 at 3:49 PM, Brent Fulgham bfulg...@gmail.com wrote: Has anyone else run into these kinds of issues, and might have some suggestions for how to better approach this problem? On the Chromium side, Brett Wilson is our master of font code. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
