Closed
Bug 1425812
Opened 7 years ago
Closed 7 years ago
COLR color font stopped working on OSX High Sierra
Categories
(Core :: Graphics: Text, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla62
Tracking | Status | |
---|---|---|
firefox62 | --- | fixed |
People
(Reporter: roel, Assigned: jfkthame)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
2.08 KB,
patch
|
lsalzman
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36 OPR/49.0.2725.39
Steps to reproduce:
Use a COLR/CPAL color font in Firefox. A simple test font can be found here:https://pixelambacht.nl/demo/color-font-test.html (it should show a green checkmark under "Microsoft COLR/CPAL") and a JavaScript check can be found here: https://pixelambacht.nl/chromacheck
Works on OSX Sierra, Not in High Sierra for any version above 56 (didn't test below).
This is mosty likely because Apple introduced native COLR/CPAL support in High Sierra, which might clash with Firefox' internal support.
Actual results:
The font is rendered in "black and white". COLR information is ignored.
Expected results:
The font should be loaded and a green checkmark should be shown on the first page, and the ChromaCheck page should show a green message saying COLR/CPAL is supported.
Component: Untriaged → Layout: Text
OS: Unspecified → Mac OS X
Product: Firefox → Core
Hardware: Unspecified → x86
Updated•7 years ago
|
Blocks: highsierra
Assignee | ||
Comment 1•7 years ago
|
||
Markus, can you confirm this? (I'm not currently on 10.13, but offhand I don't see why a change in Apple's support should have affected how we render these fonts.)
Flags: needinfo?(mstange)
Assignee | ||
Comment 2•7 years ago
|
||
I can confirm that 'COLR'-format fonts seem to be broken in Firefox on macOS 10.13; they just render solid black glyphs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mstange)
Priority: -- → P3
Assignee | ||
Comment 3•7 years ago
|
||
I checked that we're calling gfxFont::RenderColorGlyph as expected, and this in turn calls aDrawTarget->FillGlyphs() for each of the component layers that make up the color glyph, passing the correct color value from the font's palette. But the end result is that we render a solid black glyph.
I believe this used to work on 10.12, and works on 10.10 (which we're running in CI), such that our basic color-font reftests aren't failing; but if we had CI running 10.13 we'd be seeing the failure there. I don't know why the DrawTarget::FillGlyphs() calls are no longer resulting in the correct colors; AFAICS this seems to be an issue on the Graphics side.
Component: Layout: Text → Graphics: Text
Priority: P3 → P2
Hardware: x86 → All
Reporter | ||
Comment 4•7 years ago
|
||
Some observations:
I can get https://pixelambacht.nl/demo/color-font-test.html to work if I set the CPAL table version to 1 instead of 0:
<CPAL>
<version value="1"/>
<numPaletteEntries value="2"/>
<palette index="0">
...
</palette>
</CPAL>
Strangely, the COLR font used in ChromaCheck is still at CPAL table version 0, but *does* work. This was caused by compiling the font with an updated version of TTX/FontTools. Please see this commit: https://github.com/RoelN/ChromaCheck/commit/77aeaff9d76657e5caa19cd0a6ce258fa0d4abcc and specifically the changes to the COLR font: https://github.com/RoelN/ChromaCheck/commit/77aeaff9d76657e5caa19cd0a6ce258fa0d4abcc#diff-f8a43ab0d0093a27df0dc88f20498f37
I don't get why these changes suddenly made ChromaCheck's COLR font work in Firefox again, though.
Reporter | ||
Comment 5•7 years ago
|
||
(Recompiling the https://pixelambacht.nl/demo/color-font-test.html font with the new TTX/FontTools, but CPAL table version back to the original version of 0, still results in a broken COLR font)
Assignee | ||
Comment 6•7 years ago
|
||
Interesting, thanks. Does the CPAL-version-1 font work in Safari?
Assignee | ||
Comment 7•7 years ago
|
||
It appears that on HighSierra, when Core Text renders glyphs from a font with COLR/CPAL tables, it ignores any color we've set in the context and uses the colors from the font's palette; but when we render the individual glyphs that make up the layers of a composite, full-color glyphs, those individual-layer glyphs do not themselves have an inherent color (as the layer colors are associated with the "parent" composite glyph, which we don't directly ask Core Text to paint), and it just paints them black. So it looks like the easiest fix will be for us to disable our painting of the individual component glyphs on 10.13, and let Core Text do it for us.
Attachment #8981466 -
Flags: review?(lsalzman)
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•7 years ago
|
||
Try build with this patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e85469f9f3dd7a5f0787dc66eed5dc28c3130f74. This renders COLR glyphs successfully on 10.13 for me locally; we can't reftest it on treeherder because we don't have HighSierra test machines.
(We already have COLR-font reftests that would be failing because of this issue if our testing infrastructure were updated.)
Updated•7 years ago
|
Attachment #8981466 -
Flags: review?(lsalzman) → review+
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c03dea03efa7
Rely on native Core Text support for COLR/CPAL fonts on High Sierra. r=lsalzman
Comment 10•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox62:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Reporter | ||
Comment 11•7 years ago
|
||
That was quick! Thanks for the great work!
I wonder if this will also fix https://bugzilla.mozilla.org/show_bug.cgi?id=1465324?
Assignee | ||
Comment 12•7 years ago
|
||
(In reply to Roel Nieskens from comment #11)
> That was quick! Thanks for the great work!
>
> I wonder if this will also fix
> https://bugzilla.mozilla.org/show_bug.cgi?id=1465324?
I don't believe so, unfortunately; that'll require further investigation.
Updated•6 years ago
|
QA Whiteboard: [good first verify]
You need to log in
before you can comment on or make changes to this bug.
Description
•