Component: Untriaged → Layout: Text
OS: Unspecified → Mac OS X
Product: Firefox → Core
Hardware: Unspecified → x86
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.)
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
Priority: -- → P3
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
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.
(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)
Interesting, thanks. Does the CPAL-version-1 font work in Safari?
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: nobody → jfkthame
Status: NEW → ASSIGNED
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.)
Attachment #8981466 - Flags: review?(lsalzman) → review+
Pushed by email@example.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
That was quick! Thanks for the great work! I wonder if this will also fix https://bugzilla.mozilla.org/show_bug.cgi?id=1465324?
(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.
QA Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.