Buggy Font Selection in GTK Port
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. 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 somehow? Thanks, Martin
oops, I hit Send too early. Here's the reference: [1] https://bugs.webkit.org/show_bug.cgi?id=16792
On Mon, Aug 25, 2008 at 12:14:31PM +0200, Martin Sourada <martin.sourada@gmail.com> 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
Hi Martin/Mike, Although the fallback mechanism for FontConfig is there, it does not exist for the Pango implementation. So if you are using (compiling) FontPlatformDataPango.cpp file, then the problem mentioned by Martin is observed. In en_US locale, you will not be able to see Japanese/Korean etc characters. I implemented the missing functionality (in 3 files) and I am pasting the same below. Please try with the following changes and see if it helps. Thanks, Romil ---------------- WebCore/platform/graphics/gtk/FontCacheGtk.cpp const SimpleFontData* FontCache::getFontDataForCharacters(const Font& font, const UChar* characters, int length) { return new SimpleFontData(FontPlatformData(font.fontDescription(), characters, length)); } ----------------- WebCore/platform/graphics/gtk/FontPlatformData.h FontPlatformData(const FontDescription& fontDescription, const UChar *characters, int length); ----------------- WebCore/platform/graphics/gtk/FontPlatformDataPango.cpp FontPlatformData::FontPlatformData(const FontDescription& fontDescription, const UChar *characters, int length) : m_context(0) , m_font(0) , m_size(fontDescription.computedSize()) , m_syntheticBold(false) , m_syntheticOblique(false) , m_scaledFont(0) { FontPlatformData::init(); const UChar character = characters[0]; char const *family; switch (fontDescription.genericFamily()) { case FontDescription::SerifFamily: family = "serif"; break; case FontDescription::SansSerifFamily: family = "sans"; break; case FontDescription::MonospaceFamily: family = "monospace"; break; case FontDescription::NoFamily: case FontDescription::StandardFamily: default: family = "sans"; break; } m_context = pango_cairo_font_map_create_context(PANGO_CAIRO_FONT_MAP(m_fontMap)); PangoFontDescription* description = pango_font_description_new(); pango_font_description_set_absolute_size(description, fontDescription.computedSize() * PANGO_SCALE); if (fontDescription.weight() >= FontWeight600) pango_font_description_set_weight(description, PANGO_WEIGHT_BOLD); if (fontDescription.italic()) pango_font_description_set_style(description, PANGO_STYLE_ITALIC); pango_font_description_set_family(description, family); pango_context_set_font_description(m_context, description); PangoFontset *fset = pango_font_map_load_fontset (m_fontMap, m_context, description, NULL); // Get the font from the fontset which contains the best glyph for this character m_font = pango_fontset_get_font(fset, (guint)character); #if PANGO_VERSION_CHECK(1,18,0) if (m_font) m_scaledFont = cairo_scaled_font_reference(pango_cairo_font_get_scaled_font(PANGO_CAIRO_FONT(m_font))); #else // This compatibility code for older versions of Pango is not well-tested. if (m_font) { PangoFcFont* fcfont = PANGO_FC_FONT(m_font); cairo_font_face_t* face = cairo_ft_font_face_create_for_pattern(fcfont->font_pattern); double size; if (FcPatternGetDouble(fcfont->font_pattern, FC_PIXEL_SIZE, 0, &size) != FcResultMatch) size = 12.0; cairo_matrix_t fontMatrix; cairo_matrix_init_scale(&fontMatrix, size, size); cairo_font_options_t* fontOptions; if (pango_cairo_context_get_font_options(m_context)) fontOptions = cairo_font_options_copy(pango_cairo_context_get_font_options(m_context)); else fontOptions = cairo_font_options_create(); cairo_matrix_t ctm; cairo_matrix_init_identity(&ctm); m_scaledFont = cairo_scaled_font_create(face, &fontMatrix, &ctm, fontOptions); cairo_font_options_destroy(fontOptions); cairo_font_face_destroy(face); } #endif pango_font_description_free(description); } --------------- -----Original Message----- From: webkit-dev-bounces@lists.webkit.org [mailto:webkit-dev-bounces@lists.webkit.org] On Behalf Of Mike Hommey Sent: Monday, August 25, 2008 4:35 PM To: Martin Sourada Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Buggy Font Selection in GTK Port On Mon, Aug 25, 2008 at 12:14:31PM +0200, Martin Sourada <martin.sourada@gmail.com> 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Mon, Aug 25, 2008 at 06:44:53PM +0530, Romil Mittal <romil@adobe.com> wrote:
Hi Martin/Mike,
Although the fallback mechanism for FontConfig is there, it does not exist for the Pango implementation. So if you are using (compiling) FontPlatformDataPango.cpp file, then the problem mentioned by Martin is observed. In en_US locale, you will not be able to see Japanese/Korean etc characters.
Note that except if it has been fixed since release 1.0.1 (around revision 34575), the freetype backend (using fontconfig) doesn't display CJK characters in en_US locale. Mike
participants (3)
-
Martin Sourada
-
Mike Hommey
-
Romil Mittal