Closed
Bug 729993
Opened 13 years ago
Closed 9 years ago
Combining marks cannot be colored independent of their base glyphs with OpenType fonts
Categories
(Core :: Layout: Text and Fonts, defect)
Core
Layout: Text and Fonts
Tracking
()
RESOLVED
FIXED
mozilla42
Tracking | Status | |
---|---|---|
firefox42 | --- | fixed |
People
(Reporter: khaled, Unassigned)
References
Details
Attachments
(4 files)
820 bytes,
text/html
|
Details | |
697 bytes,
patch
|
jfkthame
:
review+
|
Details | Diff | Splinter Review |
48.43 KB,
image/png
|
Details | |
2.17 KB,
patch
|
Details | Diff | Splinter Review |
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).
Reporter | ||
Updated•13 years ago
|
Attachment #600052 -
Attachment mime type: text/plain → text/html
![]() |
||
Comment 1•13 years ago
|
||
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
Reporter | ||
Comment 2•12 years ago
|
||
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
Comment 3•11 years ago
|
||
HarfBuzz issue in fact. Working on it.
Comment 4•11 years ago
|
||
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.
Reporter | ||
Comment 5•9 years ago
|
||
(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.
Reporter | ||
Comment 6•9 years ago
|
||
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)
Reporter | ||
Comment 7•9 years ago
|
||
Comment 8•9 years ago
|
||
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...
Comment 10•9 years ago
|
||
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.
Comment 12•9 years ago
|
||
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.)
Updated•9 years ago
|
Attachment #8641967 -
Flags: review?(jfkthame) → review+
Comment 13•9 years ago
|
||
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
Comment 14•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/00887edc40ba https://hg.mozilla.org/mozilla-central/rev/c2183af62a8d
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox42:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in
before you can comment on or make changes to this bug.
Description
•