|Summary:||Can't load some non-latin fonts with pango backend|
|Product:||WebKit||Reporter:||Luca Ferretti <elle.uca>|
|Severity:||Normal||CC:||alp, arthur.webkid, christian, danilo, dr.khaled.hosny, fonts-bugs, jendrikseipp, martin.sourada, mrobinson, pclouds|
|Version:||528+ (Nightly build)|
Description Luca Ferretti 2008-04-17 06:05:55 PDT
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.
Comment 1 Luca Ferretti 2008-04-17 06:10:38 PDT
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/
Comment 2 Luca Ferretti 2008-04-17 06:23:00 PDT
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
Comment 3 Luca Ferretti 2008-04-17 06:27:29 PDT
Another note: I don't know if this issue is related to bug #16942
Comment 4 Garret Kelly 2008-04-21 09:00:28 PDT
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.
Comment 5 Garret Kelly 2008-04-21 09:03:13 PDT
Created attachment 20727 [details] Rendered with GtkLauncher The u.html example as rendered by revision d10ee0.
Comment 6 Adam Williamson 2008-05-15 09:02:17 PDT
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.
Comment 7 Adam Williamson 2008-05-15 09:03:27 PDT
Created attachment 21164 [details] Webkit-Pango screenshot of Wikipedia languages Screenshot of Wikipedia languages page with Webkit using the Pango backend.
Comment 8 Adam Williamson 2008-05-15 09:04:13 PDT
Created attachment 21165 [details] Webkit-Fontconfig screenshot of Wikipedia languages page Screenshot of Wikipedia languages page using Webkit with Fontconfig backend.
Comment 9 Adam Williamson 2008-05-15 09:05:28 PDT
Created attachment 21166 [details] Firefox screenshot of Wikipedia languages page Screenshot of Wikipedia languages page using Firefox (18.104.22.168). We use Firefox's Pango backend, IIRC. Note that several languages not correctly rendered in both Webkit screenshots are correctly rendered here.
Comment 10 Adam Williamson 2008-05-15 09:07:00 PDT
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.
Comment 11 Adam Williamson 2008-09-11 12:05:12 PDT
No progress with nightly 36309.
Comment 12 Martin Sourada 2008-09-11 12:08:46 PDT
(In reply to comment #11) > No progress with nightly 36309. > That's because the fix in bug #16792 is only for the FreeType backend.
Comment 13 Alp Toker 2008-11-03 23:44:57 PST
(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.
Comment 14 Adam Williamson 2008-11-25 10:27:28 PST
"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...
Comment 15 Danilo Šegan 2010-04-22 03:29:01 PDT
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