[webkit-dev] Buggy Font Selection in GTK Port
martin.sourada at gmail.com
Mon Aug 25 03:14:31 PDT 2008
Some of you might be aware of the problem with font selection in the GTK
Port . This is really pain in the ass especially on linux where we
usually don't have any full-Unicode coverage and rely heavily on font
fall-back rules. This is broken in WebKitGTK in a way that e.g. when you
use latin-script locales (en_*, etc.) some foreign scripts like Kanji,
Hiragana, Katakana, ... are not rendered (with pango backend they are
just almost left out of the layout, with freetype backend black-bordered
rectangle is displayed instead) when the glyphs are not in the font
selected by WebKit for the page element, even though font used usually
for substitution is present.
In the bug report it is stated, that the devs haven't come up a definite
solution to that so I propose one (unfortunately I am not [yet] familiar
with WebKit code and C++ [although I am fluent in C], but I'd like to
help as much as possible). First the problem:
In web browser we face two issues with font selection.
First is CSS font selection which is designed to select available font
from the font list given in the CSS style - i.e. if you have in CSS
font-family = Arial, "Liberation Sans", sans-serif and you have
Liberation Sans but not Arial on your computer then Liberation Sans is
Second is font substitution for missing glyphs. E.g. DejaVu Sans does
not contain Japanese glyphs and thus is usually substituted by VLGothic
when these glyphs are needed.
The first issue is already handled by WebKit and is AFAIK working
correctly. The second issue is working correctly system-wide, but not in
WebKit-gtk. Since the second issue is system wide the Pango library was
designed to handle it and has pretty good algorithms to solve this
problem - and thus it works good in most application. However,
WebKit-gtk does not use these.
My idea of solution to this bug is to treat these issues separately,
because they are separate. Let the CSS font selection be done by WebKit
and leave the glyph font substitution to be handled by pango/freetype.
Is this solution feasible? Does it seem implementable? Can I help
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.webkit.org/pipermail/webkit-dev/attachments/20080825/16665d51/attachment.bin
More information about the webkit-dev