Bug 72837 - [Gtk] WebKitGtk fails to connect Arabic glyphs when using WebFonts
Summary: [Gtk] WebKitGtk fails to connect Arabic glyphs when using WebFonts
Status: RESOLVED DUPLICATE of bug 20783
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL: https://bugs.launchpad.net/nuvola-pla...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-20 14:57 PST by Jiří Janoušek
Modified: 2012-10-27 12:49 PDT (History)
4 users (show)

See Also:


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 Details
new scrrenshot (38.29 KB, image/png)
2012-10-27 12:17 PDT, Badry Darkoush
no flags Details
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 Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiří Janoušek 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
Comment 1 Alexey Proskuryakov 2011-11-21 16:43:09 PST
Is this limited to Google Music, or is it an issue with Arabic text on any sites?
Comment 2 Badry Darkoush 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
Comment 3 Eric Seidel (no email) 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.
Comment 4 Martin Robinson 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.
Comment 5 Jiří Janoušek 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.
Comment 6 Eric Seidel (no email) 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).
Comment 7 Martin Robinson 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.
Comment 8 Badry Darkoush 2012-10-27 12:17:34 PDT
Created attachment 171100 [details]
new scrrenshot

new screenshot
Comment 9 Badry Darkoush 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
Comment 10 Eric Seidel (no email) 2012-10-27 12:44:52 PDT
Yup.  That's completely illegible arabic. :(  Sad to hear it's still broken.
Comment 11 Eric Seidel (no email) 2012-10-27 12:46:51 PDT
Is this just a dupe of bug 20783?
Comment 12 Martin Robinson 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 ***