[webkit-dev] Buggy Font Selection in GTK Port

Romil Mittal romil at adobe.com
Mon Aug 25 06:14:53 PDT 2008


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 at lists.webkit.org [mailto:webkit-dev-bounces at lists.webkit.org] On Behalf Of Mike Hommey
Sent: Monday, August 25, 2008 4:35 PM
To: Martin Sourada
Cc: webkit-dev at 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 at 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 at lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


More information about the webkit-dev mailing list