Closed Bug 772640 Opened 8 years ago Closed 7 years ago
Arabic U+0622 not rendered correctly with Graphite rendering
137.92 KB, application/octet-stream
14.24 KB, image/jpeg
fix for incorrect glyph positioning in multi-glyph RTL clusters generated by Graphite shaping. try: -b o -p all -u reftest
1.44 KB, patch
|Details | Diff | Splinter Review|
190.96 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11 Steps to reproduce: Enable Graphite rendering by going to about:config and setting gfx.font_rendering.graphite.enabled true. With Scheherazade font (in development -- contains both OpenType and Graphite logic) installed, open and display Test0622.html file. (both files in attached zip) Actual results: The Maddah mark is displayed too far to left when rendering U+0622 ARABIC LETTER ALEF WITH MADDA ABOVE. (The canonically equivalent sequence U+0627 ARABIC LETTER ALEF + U+0653 ARABIC MADDAH ABOVE, also in the test file, displays properly). Expected results: 0622 should look identical to the sequence 0627+0653. The font first decomposes 0622 into the same glyphs used for 0627 and 0653. After that the two cases are identical, so should render identically. To see what it should look like, disable Graphite rendering (go to about:config and set gfx.font_rendering.graphite.enabled false) and see the OpenType result. Fails on Linux and Windows with v13.0.1. Also failed on the nightly 16.0a1 (2012-07-10). LibreOffice is another Graphite-enabled app that renders these correctly.
Confirming that I see the same discrepancy on OS X nightly, too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
The problem arises when multiple glyphs are generated for a single source character, so that our textrun puts them into a DetailedGlyphs array; the x-positioning wasn't being handled properly for RTL runs there. This should fix the problem, and results in the same rendering through either OpenType or Graphite paths with this font (modulo minor positioning discrepancies due to precision/rounding differences in the shapers).
Attachment #671800 - Flags: review?(jdaggett)
Tryserver builds with this patch are available at http://email@example.com/. Bob, if you could test and confirm that this resolves the problems you've been seeing, that'd be great - thanks!
Looks fine but this needs a reftest (whether that's based on the testcase here or something else is your call).
Tests to verify that the precomposed and decomposed versions of alef-madda render the same, under both OpenType and Graphite shaping and in both LTR and RTL text runs. (Without the fix here, the graphite test fails in the RTL/precomposed case.) Tryserver run at https://tbpl.mozilla.org/?tree=Try&rev=db1de1d04318.
Attachment #672409 - Flags: review?(jdaggett)
(In reply to Jonathan Kew (:jfkthame) from comment #4) > Tryserver builds with this patch are available at > http://firstname.lastname@example.org- > e2e1bf34d7bb/. Bob, if you could test and confirm that this resolves the > problems you've been seeing, that'd be great - thanks! Confirming that this appears to correct the problems I was seeing. It also appears to fix bug 780697 which we suspected was a duplicate of this. Thanks, Jonathan!
Assignee: nobody → jfkthame
Target Milestone: --- → mozilla19
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.