Bug 72837

Summary: [Gtk] WebKitGtk fails to connect Arabic glyphs when using WebFonts
Product: WebKit Reporter: Jiří Janoušek <janousek.jiri>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: eric, free.programmer4linux, mrobinson, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
URL: https://bugs.launchpad.net/nuvola-player/+bug/892449
Attachments:
Description Flags
Screenshot with Google Music in Midori (webkitgtk-based browser)
none
new scrrenshot
none
font-face Demo screenshot on Midori 0.4.3 still rendering incorrectly none

Jiří Janoušek
Reported 2011-11-20 14:57:03 PST
Created attachment 116001 [details] Screenshot with Google Music in Midori (webkitgtk-based browser) The Arabic text rendering in song name appears with letters not connected
Attachments
Screenshot with Google Music in Midori (webkitgtk-based browser) (149.89 KB, image/png)
2011-11-20 14:57 PST, Jiří Janoušek
no flags
new scrrenshot (38.29 KB, image/png)
2012-10-27 12:17 PDT, Badry Darkoush
no flags
font-face Demo screenshot on Midori 0.4.3 still rendering incorrectly (106.15 KB, image/png)
2012-10-27 12:20 PDT, Badry Darkoush
no flags
Alexey Proskuryakov
Comment 1 2011-11-21 16:43:09 PST
Is this limited to Google Music, or is it an issue with Arabic text on any sites?
Badry Darkoush
Comment 2 2011-11-21 22:59:03 PST
(In reply to comment #1) > Is this limited to Google Music, or is it an issue with Arabic text on any sites? No, Arabic websites render correctly,see attached screenshot for Midori 0.4.0 link: https://launchpadlibrarian.net/85465373/midori-arabic.png
Eric Seidel (no email)
Comment 3 2012-10-27 01:50:46 PDT
Is this still an issue? I've seen several bugs go by which have talked about changes to WebKitGtk's international text rendering.
Martin Robinson
Comment 4 2012-10-27 11:20:26 PDT
Jiří can you look at the web inspector and check whether or not the fonts used on that page are web fonts? This may be a duplicate of: https://bugs.webkit.org/show_bug.cgi?id=18552 The fix would be to switch to HarfBuzz for complex text rendering and to remove the Pango backend entirely. I'm working on this now.
Jiří Janoušek
Comment 5 2012-10-27 11:46:23 PDT
(In reply to comment #3) > Is this still an issue? I've seen several bugs go by which have talked about changes to WebKitGtk's international text rendering. FYI, I cannot check whether the issue is still present, because I don't have any experiences with arabic text. I only forwarded an issue reported by Badry Darkoush to a bug tracker of Nuvola Player. (In reply to comment #4) > Jiří can you look at the web inspector and check whether or not the fonts used on that page are web fonts? This may be a duplicate of: https://bugs.webkit.org/show_bug.cgi?id=18552 Yes, the list of songs uses web font Proxima Nova.
Eric Seidel (no email)
Comment 6 2012-10-27 12:01:26 PDT
What the reporter is noting is that all of the letters are rendered in their isolated forms, instead of connecting. Arabic is always cursive (no block letters), so depending on where in a word a letter appears, it uses one of 4 different forms (glyphs) to connect to the surrounding letters. The image attached to this bug shows all the letters spaced (seemingly) correctly, but always drawn in their "isolated" forms. Meaning they just randomly overlap each other in ways which are nonsensical and illegible. Take for example the first (right-most) word in song 3. It should read as: "احب", notice how the 2nd (middle) and 3rd (left-most) letter join together, instead of sitting next to each other "ا ح ب" like they do in the image (I had to add spaces between the letters to make them use their isolated forms and not connect.) Anyway, any other browser you can find for your platform I'm sure gets this right, and I would be shocked if this bug isn't already resolved today. http://jehazy.com/webfont/ is an example of arabic rendered with a WebFont for a different bug. A non-arabic speaker could presumably use that to confirm if the arabic looks right in Midori (and then we can close this).
Martin Robinson
Comment 7 2012-10-27 12:08:41 PDT
(In reply to comment #6) > Anyway, any other browser you can find for your platform I'm sure gets this right, and I would be shocked if this bug isn't already resolved today. Sadly, this is still an issue for WebKitGTK+, though only with web fonts. If all goes well, it should be fixed in the next release. It's only been rather recently that the libraries necessary to do this have existed stand-alone for the free desktop (with HarfBuzzNG 1.0). In the past, HarfBuzz was embedded directly into libraries like Pango -- and this is the approach that Chromium on Linux used. Now that HarfBuzz is a standalone library, we can use it in WebKitGTK+ (where embedding dependencies is more culturally taboo). The reason that Pango doesn't work for this usecase is that it's only designed to work with installed fonts. Firefox had a "hacky" subclass of some core Pango class that worked around the issue.
Badry Darkoush
Comment 8 2012-10-27 12:17:34 PDT
Created attachment 171100 [details] new scrrenshot new screenshot
Badry Darkoush
Comment 9 2012-10-27 12:20:30 PDT
Created attachment 171101 [details] font-face Demo screenshot on Midori 0.4.3 still rendering incorrectly font-face Demo from http://jehazy.com/webfont/ screenshot on Midori 0.4.3 still rendering incorrectly and characters not connected
Eric Seidel (no email)
Comment 10 2012-10-27 12:44:52 PDT
Yup. That's completely illegible arabic. :( Sad to hear it's still broken.
Eric Seidel (no email)
Comment 11 2012-10-27 12:46:51 PDT
Is this just a dupe of bug 20783?
Martin Robinson
Comment 12 2012-10-27 12:49:39 PDT
I can't say for sure, but I think that's a pretty safe categorization. If the switch to HarfbuzzNG doesn't fix this issue, we can re-open it and go from there: *** This bug has been marked as a duplicate of bug 20783 ***
Note You need to log in before you can comment on or make changes to this bug.