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)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: ehsan.akhgari, Assigned: jfkthame)
References
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
jtd
:
review+
|
Details | Diff | Splinter Review |
see the screenshot: http://grab.by/7Aug
The letters appear in isolated form, instead of their correct joined form.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Assignee | ||
Comment 1•14 years ago
|
||
(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>ابجد</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
Assignee | ||
Comment 2•14 years ago
|
||
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;">ابجد
works, but
data:text/html,<div style="font-family:Geeza Pro;font-weight:bold">ابجد
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.
Assignee | ||
Comment 3•14 years ago
|
||
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)
Assignee | ||
Updated•14 years ago
|
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
Updated•14 years ago
|
blocking2.0: ? → betaN+
Reporter | ||
Comment 4•14 years ago
|
||
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.
Comment 5•14 years ago
|
||
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.
Updated•14 years ago
|
Attachment #493361 -
Flags: review?(jdaggett) → review+
Assignee | ||
Comment 6•14 years ago
|
||
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.
Description
•