Closed Bug 729993 Opened 8 years ago Closed 4 years ago

Combining marks cannot be colored independent of their base glyphs with OpenType fonts

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
firefox42 --- fixed

People

(Reporter: dr.khaled.hosny, Unassigned)

References

Details

Attachments

(4 files)

Some times it is very useful to be able to color combining marks (e.g. Arabic vowel marks) independent of their base glyphs (for pedagogical reasons, to annotate them etc.).

But this seems not to be currently supported, see attached file (marks are not colored in the first line when they should and they shouldn't be colored in the second line but they are). Thankfully the shaping and OpenType substitution and positioning are correct across colors (unlike other applications).
Attachment #600052 - Attachment mime type: text/plain → text/html
This works for me with a current trunk build on Mac.

I do see the described behavior on Linux and Windows...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Combining cannot be colored independent of their base glyphs → Combining marks cannot be colored independent of their base glyphs on Linux and Windows
I just tested this on Mac. I get the same behavior as Linux with OpenType fonts (e.g. Amiri), but with AAT fonts (e.g. Geeza Pro) I get the expected behavior.
Summary: Combining marks cannot be colored independent of their base glyphs on Linux and Windows → Combining marks cannot be colored independent of their base glyphs with OpenType fonts
HarfBuzz issue in fact.  Working on it.
I wonder if supporting this is worth the complexity without the layout developers of other browsers on board. If authors can't rely on this cross-browser, we pay the price for complexity without authors really being able to use the feature.
(In reply to Henri Sivonen (:hsivonen) (not reading bugmail or doing reviews until 2015-08-03)) from comment #4)
> I wonder if supporting this is worth the complexity without the layout
> developers of other browsers on board. If authors can't rely on this
> cross-browser, we pay the price for complexity without authors really being
> able to use the feature.

Safari and Chrome show the expected marks but they break the shaping, Firefox gets the shaping right. Any way the fix should be as simple as setting HarfBuzz cluster level now, but this needs bug 1146151 to land first.
Depends on: 1146151
Here is a patch that should fix this issue.

For reference, the root of this issue is that HarfBuzz assigns the cluster value of the base characters to its marks. Gecko uses the cluster values for the glyph to character mapping, so it will think that the glyphs representing the base character and the combining mark(s) all belong to the base character and will apply its colour attribute (if any) to it, and it will not apply the attributes of the combining marks as there are no glyphs that belong to it.

Using HB_BUFFER_CLUSTER_LEVEL_MONOTONE_CHARACTERS cluster level will cause HarfBuzz to give the combining marks separate cluster values, so the glyph to character mapping will be work and the attributes will be applied to the marks separately.
Attachment #8641967 - Flags: review?(jfkthame)
Yes, once the harfbuzz update lands I think we can do this. I'll push it to tryserver to check there's no unexpected impact on unit tests...
Unfortunately, it turns out that changing the HB_BUFFER_CLUSTER_LEVEL has unexpected side-effects on rendering behavior. Reported to Behdad. We'll need to get that fixed before we land the patch here.
Here are the two fixes needed in harfbuzz to avoid shaping regressions here. (These patches were marked LGTM and merged upstream by Behdad; see https://github.com/behdad/harfbuzz/pull/123 and https://github.com/behdad/harfbuzz/pull/124. I'm considering that as equivalent to r+ here.)
Attachment #8641967 - Flags: review?(jfkthame) → review+
url:        https://hg.mozilla.org/integration/mozilla-inbound/rev/00887edc40ba14b9251eb52284898b855e07b93d
changeset:  00887edc40ba14b9251eb52284898b855e07b93d
user:       Jonathan Kew <jkew@mozilla.com>
date:       Sun Aug 09 22:01:28 2015 +0100
description:
Bug 729993 - Cherry-pick harfbuzz fixes for finer-grained cluster support (9099e48e29, c7dfe316f8). r=behdad (upstream)

url:        https://hg.mozilla.org/integration/mozilla-inbound/rev/c2183af62a8d095b43ae3b34e535a72a79696b4a
changeset:  c2183af62a8d095b43ae3b34e535a72a79696b4a
user:       Khaled Hosny <khaledhosny@eglug.org>
date:       Sun Aug 09 22:01:32 2015 +0100
description:
Bug 729993 - Use finer HarfBuzz cluster level. r=jfkthame
https://hg.mozilla.org/mozilla-central/rev/00887edc40ba
https://hg.mozilla.org/mozilla-central/rev/c2183af62a8d
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Depends on: 1238243
Depends on: 1395926
You need to log in before you can comment on or make changes to this bug.