On Mon, Aug 25, 2008 at 12:14:31PM +0200, Martin Sourada <[EMAIL PROTECTED]> wrote: > Hi, > > Some of you might be aware of the problem with font selection in the GTK > Port [1]. 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 > selected. > > 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.
Theorically, there is no need for pango, there. Fontconfig already has fallback possibilities. Mike _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
