You need to
before you can comment on or make changes to this bug.
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.
Created an attachment (id=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/
Created an attachment (id=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
Another note: I don't know if this issue is related to bug #16942
Created an attachment (id=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.
Created an attachment (id=20727) [details]
Rendered with GtkLauncher
The u.html example as rendered by revision d10ee0.
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.
Created an attachment (id=21164) [details]
Webkit-Pango screenshot of Wikipedia languages
Screenshot of Wikipedia languages page with Webkit using the Pango backend.
Created an attachment (id=21165) [details]
Webkit-Fontconfig screenshot of Wikipedia languages page
Screenshot of Wikipedia languages page using Webkit with Fontconfig backend.
Created an attachment (id=21166) [details]
Firefox screenshot of Wikipedia languages page
Screenshot of Wikipedia languages page using Firefox (220.127.116.11). We use Firefox's Pango backend, IIRC. Note that several languages not correctly rendered in both Webkit screenshots are correctly rendered here.
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.
No progress with nightly 36309.
(In reply to comment #11)
> No progress with nightly 36309.
That's because the fix in bug #16792 is only for the FreeType backend.
(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.
"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
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...
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
There is no longer a Pango backend after http://trac.webkit.org/changeset/137263.