Details at http://crbug.com/133720.
WebKit ToT mac port doesn't render Arabic script correctly when there is ZWNJ in the text. Test case is attached.
The stable version of Safari can render it correctly. The difference comes from http://trac.webkit.org/changeset/95391. The change fixed a bug related with combining character sequence and handled ZWJ and ZWNJ as a part of combining character sequence. The cause is that fontDataForCombiningCharacterSequence() is failing when the sequence contains ZWNJ and the font doesn't contain glyph for ZWNJ. As the result, the word is divided into two complex text runs and they are rendered in isolated form.
To fix the problem, I suggest:
- Treat ZWJ and ZWNJ as base characters. I don't think ZWJ and ZWNJ compose a combining character sequence because they just tell whether to form cursive connection or not (they aren't combined with other character).
- If we see a ZWJ, don't separate a complex text run at that point so that CoreText can handle it.
I'll post a patch soon.
Created attachment 149220 [details]
Created attachment 149221 [details]
Could you take a look?
Does this affect any real life web sites?
(In reply to comment #5)
> Does this affect any real life web sites?
I think so. http://www.google.com/intl/fa/goodtoknow/ is an example. I'll attach a screenshot of WebKit nightly and Firefox 13.
Created attachment 149704 [details]
screenshot of WebKit nightly and Firefox13
Given that Geeza Pro doesn't have a ZWNJ glyph, and it's default Arabic font on OS X, pretty much any Persian website that doesn't request Arial or Tahoma is broken, as well as any using Google's Droid Arabic Naskh as a webfont. I'm sure there are more fonts without those glyphs out there...
Comment on attachment 149221 [details]
Clearing flags on attachment: 149221
Committed r121643: <http://trac.webkit.org/changeset/121643>
All reviewed patches have been landed. Closing bug.