Closed Bug 614903 Opened 14 years ago Closed 14 years ago

Arabic joining broken in tab titles on Mac

Categories

(Core :: Layout: Text and Fonts, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: ehsan.akhgari, Assigned: jfkthame)

References

Details

(Keywords: regression)

Attachments

(1 file)

see the screenshot: http://grab.by/7Aug

The letters appear in isolated form, instead of their correct joined form.
blocking2.0: --- → ?
(In reply to comment #0)
> see the screenshot: http://grab.by/7Aug
> 
> The letters appear in isolated form, instead of their correct joined form.

I don't see a screenshot at the URL given, but I see the problem with a simple testcase here:

data:text/html,<head><title>&#x627;&#x628;&#x62c;&#x62f;</title></head>

shows a tab title with isolated letters.

Setting gfx.font_rendering.harfbuzz.level to 1 restores the proper behavior. I think the issue here is that we're using harfbuzz with a font that only provides AAT tables; we're supposed to defer to CoreText for those. I'll look into it.

(I think this should block 2.0, as it's a serious regression.)
Assignee: nobody → jfkthame
Blocks: 603879
The issue here is that the default Arabic font (Geeza Pro) works fine, but its bold face doesn't - and tab titles are bold. And so

data:text/html,<div style="font-family:Geeza Pro;">&#x627;&#x628;&#x62c;&#x62f;

works, but

data:text/html,<div style="font-family:Geeza Pro;font-weight:bold">&#x627;&#x628;&#x62c;&#x62f;

doesn't.

And this is because Geeza Pro is (as expected on OS X) an AAT-only font, and we therefore shape using the CoreText backend. But Geeza Pro Bold has a GPOS table, in addition to its AAT tables; we detect this, conclude that it's an OpenType Layout-enabled font, and shape it using harfbuzz. But it does not actually have Arabic OpenType support; there's no GSUB, and the GPOS includes only a Latin-tagged kerning table (for some Arabic glyphs.... huh??).

To fix this, we'll need to be a bit more thorough in examining the font before deciding whether to use the harfbuzz path.
This makes us prefer CoreText shaping for complex-script fonts that have AAT tables, even if they also have some OpenType tables (like Geeza Pro Bold).
Attachment #493361 - Flags: review?(jdaggett)
Attachment #493361 - Attachment description: patch, v1 - require GSUB presence to treat a font as OpenType-capable → patch, v1 - prefer CoreText path for complex-script fonts if AAT tables are present
Sorry for linking to the wrong screenshot!

CCing Behdad in case this is something which can be detected and worked around at harfbuzz level as well.
Thanks.

1) Would be nice if someone can write a CoreText backend for HarfBuzz ;)
2) Arabic fallback shaping in HarfBuzz will happen at somepoint, but that's not the right fix here.
3) No idea how to improve the OpenType-support detection.  Prefering AAT when available sounds right to me.
Attachment #493361 - Flags: review?(jdaggett) → review+
http://hg.mozilla.org/mozilla-central/rev/1788c427e7f1
NB: changeset has incorrect bug number in the commit message :(
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.