[Webkit-unassigned] [Bug 6626] Arabic & Farsi rendered with no shaping (all glyphs separate, unreadable!)
bugzilla-daemon at opendarwin.org
bugzilla-daemon at opendarwin.org
Thu Mar 9 04:33:14 PST 2006
http://bugzilla.opendarwin.org/show_bug.cgi?id=6626
------- Comment #12 from opendarwin.org at mitzpettel.com 2006-03-09 04:33 PDT -------
Created an attachment (id=6955)
--> (http://bugzilla.opendarwin.org/attachment.cgi?id=6955&action=view)
ICU shaping applied
What Windows does when the font does not contain shaping instructions (and
maybe even when it does) is perform shaping according to the Unicode standard
(Chapter 8 and http://www.unicode.org/Public/UNIDATA/ArabicShaping.txt),
relying on the fact that initial/dual/final/isolated forms are distinct
characters. ATSUI does not shape unless the font contains instructions.
There was a similar problem with character mirroring (bug 3435), where the fix
was to determine heuristically if ATSUI is going to mirror, and if not, invoke
ICU routine to do the mirroring.
This screenshot demonstrates that a similar approach may work here. It was
produced by invoking the ICU function u_shapeArabic() to on all
(ATSUI-rendered) text on the page. The real fix would have to:
1) Use some heuristic (or hard-coded list of those MS Office-originating fonts)
to decide that a given font contains Arabic, does not contain shaping
instructions, and does contain 'cmap' entries for the contextual forms.
2) Decide when a run needs to be shaped by u_shapeArabic() (which is similar to
deciding if it contains Arabic characters). This may belong in shouldUseATSU.
--
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list