Bug 18546 – Can't load some non-latin fonts with pango backend

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

[Luca Ferretti]

WebKitGtk seem unable to load some non-latin text using the pango backend (honestly I haven't tried with fontconfig backend...), while is able to do the same with other.

See the attached Epiphany screenshots.

[Luca Ferretti]

Created attachment 20622 [details]
Epiphany running with Gecko backend

The screenshot show the language list on wikipedia.org homepage.

There are 5 languages with no font available on the system (km, bo, got, my, and chr) all showed with white boxes, but all others are fine.

Note: it's the epiphany installed by vendor under /usr/

[Luca Ferretti]

Created attachment 20623 [details]
Epiphany running with WebKit backend

The same page loaded in Epiphany-Webkit (installed with jhbuild under /opt/gnome2 and using --enable-font-backend=pango).

There are some holes due to links to local pages not showed. The list of languages (well, not real language codes, just the XX used in XX.wikipedia.org addresses) is:
 * ja, ru, uk in 100.000+ section
 * be, bg, el, ko, he, ka, mk, sr, sh in 10.000+ section
 * am, be-x-old, cv, zh-classica, hy, os, kk, tg. woo, zh-yue in 1000+ section
 * other in 100+ section

Note also that it's not a Pango/Gtk+ issue or something related to jhbuild sandbox, 'cause moving the mouse pointer over the "holes", on the statusbas appears the full link to the page, showing the proper non-latin fonts. In this screenshot is visible the text for ru.wikipedia.org

[Luca Ferretti]

Another note: I don't know if this issue is related to bug #16942

[Garret Kelly]

Created attachment 20725 [details]
Test case demonstrating inability to fallback when glyphs are missing from primary font

One would expect that the attached file render non-latin characters as either missing-glyph indicators if they are truly unavailable on the system, or that the missing glyphs be taken from other fonts which have the missing unicode page coverage.

[Garret Kelly]

Created attachment 20727 [details]
Rendered with GtkLauncher

The u.html example as rendered by revision d10ee0.

[Adam Williamson]

Very similar problem here. Attaching my screenshot for comparison. My system font is DejaVu Sans. I'll also attach a screenshot from the fontconfig backend, which has similar trouble, and a screenshot from Firefox for comparison. There's some that Firefox doesn't get either (probably as I have no matching font on my system), but Firefox gets several that both Webkit backends miss (notably CJK) and there's none that Webkit gets but Firefox misses.

[Adam Williamson]

Created attachment 21164 [details]
Webkit-Pango screenshot of Wikipedia languages

Screenshot of Wikipedia languages page with Webkit using the Pango backend.

[Adam Williamson]

Created attachment 21165 [details]
Webkit-Fontconfig screenshot of Wikipedia languages page

Screenshot of Wikipedia languages page using Webkit with Fontconfig backend.

[Adam Williamson]

Created attachment 21166 [details]
Firefox screenshot of Wikipedia languages page

Screenshot of Wikipedia languages page using Firefox (2.0.0.14). We use Firefox's Pango backend, IIRC. Note that several languages not correctly rendered in both Webkit screenshots are correctly rendered here.

[Adam Williamson]

Additional information: this is Webkit SVN 33029. System font, as noted, is DejaVu Sans. I have fonts including CJK glyphs available (as the Firefox screenshot shows). Pango version is 1.20.2.

[Adam Williamson]

No progress with nightly 36309.

[Martin Sourada]

(In reply to comment #11)
> No progress with nightly 36309.
> 

That's because the fix in bug #16792 is only for the FreeType backend.

[Alp Toker]

(In reply to comment #12)
> (In reply to comment #11)
> > No progress with nightly 36309.
> > 
> 
> That's because the fix in bug #16792 is only for the FreeType backend.
> 

Yes, the 'FreeType backend' now contains the latest Pango code as well and the 'Pango backend' is considered obsolete at the moment. We do need to make this clearer.

[Adam Williamson]

"Yes, the 'FreeType backend' now contains the latest Pango code as well and the
'Pango backend' is considered obsolete at the moment. We do need to make this
clearer."

Can you give me some more info on this? How are we supposed to use / test the latest Pango stuff, then? The 'FreeType backend' seems to build without any Pango build dependencies...

[Danilo Šegan]

There are some things that work with Pango and not with FreeType: "locl" tables support. I've filed a separate bug at https://bugs.webkit.org/show_bug.cgi?id=37984

[Martin Robinson]

There is no longer a Pango backend after http://trac.webkit.org/changeset/137263.