Changes between Version 9 and Version 10 of WebKitGTKFonts


Ignore:
Timestamp:
Dec 11, 2012 2:17:55 AM (11 years ago)
Author:
Martin Robinson
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • WebKitGTKFonts

    v9 v10  
    11= The Font Backends =
    22
    3 WebKitGTK+ currently supports two font backends: FreeType and Pango. This is somewhat of a misnomer, because even though the FreeType backend uses Fontconfig for selection and Freetype for reading font data / creating custom fonts, it still uses Pango (specifically PangoCairo) for complex text layout (WebCore/platform/graphics/gtk/FontGtk.cpp). Currently there are quite a few issues related to font layout and selection.
     3WebKitGTK+ currently supports a single font backend which uses Fontconfig for selection, Freetype for rasterization, and Harfbuzz for complex text shaping. We recently switched from supporting an optional Pango-based backend. Now the "Freetype" backend is the only one available.
    44
    5 = Goals =
    6 1. '''Use HarfBuzz directly''' PangoCairo uses HarfBuzz internally, but switching away from PangoCairo has benefits. Behdad Esfahbod, author of HarfBuzz, also summarizes why it is best for [http://behdad.org/text/| browsers to use HarfBuzz directly]:
    7   Firefox uses Pango. Firefox 2 was hacked to use PangoLayout API. That was very abusive and inherently inefficient. Firefox 3 has got a new layout engine that is completely based on cairo. The Linux port subclasses PangoFcFontMap to be able to support both CSS text selection as well as web fonts. By doing that it is essentially reimplementing most of Pango and only using the shaping logic. It makes much more sense to use HarfBuzz directly, and Mozilla is now working on getting HarfBuzz ready for that.
    8 Additionally, using HarfBuzz directly will allow us to share layout and shaping code with Chromium.
     5== Remaining font bugs ==
    96
    10 === Caveats for replacing PangoCairo with HarfBuzz ===
    11 {{{
    12   (02:49:36 PM) mrobinson: Xan was saying that you mentioned something the GTK+ port does well, perhaps even better than Chromium.
    13   (02:49:47 PM) evmar: complex text, definitely
    14   (02:49:53 PM) evmar: we don't use pango
    15   (02:49:55 PM) mrobinson: Ah.
    16   (02:49:57 PM) mrobinson: The shaping?
    17   (02:50:02 PM) evmar: it turns out that harfbuzz is just one small piece of the complex text stack
    18   (02:50:13 PM) evmar: and that there's a bunch of stuff in pango that is annoying to replicate
    19   (02:51:06 PM) mrobinson: Hrm. I know that HarfBuzz can do things like form ligatures and conbine glyphs.
    20   (02:51:12 PM) mrobinson: What sort of thing can't it do?
    21   (02:51:23 PM) evmar: yeah, that is the sort of thinking we did, too :)
    22   (02:51:37 PM) evmar: uh
    23   (02:51:45 PM) evmar: mirroring (like parenthesis)
    24   (02:52:05 PM) evmar: dealing with broken fonts (we had to hack around bad advances in some arabic font, i forget how it works now)
    25   (02:52:32 PM) evmar: renormalizing text (harfbuzz expects "correct" text, i think pango knows to reorder it before giving it to harfbuzz)
    26 }}}
     7There are still some font bugs remaining. Here's a list to help us keep track of them:
    278
    28 2. '''Remove the Pango backend''' Maintaining the Pango backend is a serious support burden and since we'll be using HarfBuzz to do layout and shaping, is very redundant. For GTK+ ports that do not want to depend on Fontconfig, there is the option of using native Win32 font selection. The WinCairo port is already using this.
    29 
    30 = FreeType/Fontconfig Font Backend Bugs =
    31 A collection of font-related bugs from Bugzilla:
    32 
    33  * [https://bugs.webkit.org/show_bug.cgi?id=26741 Share complex text support with Chromium Linux] (the switch to HarfBuzz)
    34  * [https://bugs.webkit.org/show_bug.cgi?id=30532 Wrong font size calculated on google.com] (likely an Epiphany bug)
    35  * [https://bugs.webkit.org/show_bug.cgi?id=20783 (GTK) @font-face fonts do not have complex text support]
    36 
    37 These two may well be related. They both deal with fallback CJK fonts:
     9 * [https://bugs.webkit.org/show_bug.cgi?id=35583 if font-family lists several generic families, the last one takes precedence]
     10 * [https://bugs.webkit.org/show_bug.cgi?id=76048 GTK: fast/text/font-kerning.html fails]
    3811 * [https://bugs.webkit.org/show_bug.cgi?id=37984 WebKit freetype backend doesn't support "locl" tables]
    39  * [https://bugs.webkit.org/show_bug.cgi?id=26003 Has inconsistent font selection behavior compared with other GTK2 apps]
    40 
    41 == Pango backend bugs ==
    42  * [https://bugs.webkit.org/show_bug.cgi?id=18546 Can't load some non-latin fonts with pango backend]
    43  * [https://bugs.webkit.org/show_bug.cgi?id=18552 Downloadable fonts don't work with pango backend]
    44  * [https://bugs.webkit.org/show_bug.cgi?id=18552 WebKit crashes when running acid3 on Linux using font backend Pango]
    45 
     12 * [https://bugs.webkit.org/show_bug.cgi?id=31931 CPU spikes when rendering, spending time loading compressed pcf fonts]
     13 * [https://bugs.webkit.org/show_bug.cgi?id=77437 freetype port: font fallback mechanism can try harder]
     14 *