We currently render COLRv0 glyphs in thebes via gfxFont::RenderColorGlyph. We should extend this to handle the COLRv1 table, with its richer set of rendering and compositing operations.

Chromium 98 has implemented it.

Depends on D152036

Depends on D152037

Depends on D152038

The above patches appear to work well for a number of COLRv1 fonts I have tried. Not yet implemented: any validation of the tables, they're just assumed to be well-formed; and any support for the variation versions of the paint records.

Depends on D152041

(Also converted a bunch of internal struct definitions to use type names
based on the OT spec instead of the AutoSwap_* types from gfxFontUtils.)

Depends on D152162

Depends on D153076

Depends on D153077

Normalize gradient stops to match Chrome's rendering.

Can you provide a bit of info as to what the issue was?

Is there an ambiguity in the OT spec that should be clarified to ensure interoperability between implementations?

(In reply to pgcon6 from comment #11)

Normalize gradient stops to match Chrome's rendering.

Can you provide a bit of info as to what the issue was?

Is there an ambiguity in the OT spec that should be clarified to ensure interoperability between implementations?

This was about how things work when the color line isn't defined from stops at 0.0 to 1.0 but instead (say) from 0.2 to 0.8 ... my initial implementation didn't handle this, and I was getting a result that differed from what I see in Chrome. I don't think it was particularly a spec issue, just a mismatch between the OT gradient expectations and our graphics backend that needed to be accounted for.

Depends on D152038

Depends on D153078

Depends on D153871

Depends on D153872

Depends on D153873

Depends on D153874

Depends on D153875

Depends on D153876

Depends on D153877

Depends on D153878

Depends on D153879

Depends on D153880

The font here is a copy of Ahem with a COLRv1 table added, using various of the
COLRv1 paint and transform tables. This is far from an exhaustive set of tests,
but serves to check that basic rendering functionality is working.

The reference file uses CSS blocks filled with gradients, etc, to simulate the
expected rendering of the colored Ahem glyphs. This is unlikely to be a perfect
match in any but the simplest cases, thanks to antialiasing, pixel-rounding, etc.,
but the results are visually indistinguishable, or virtually so, and the amount
of "fuzz" is far less than the differences would be in the case of the COLRv1
glyphs actually being mis-rendered.

(There's a try run without the fuzz annotations at
https://treeherder.mozilla.org/jobs?repo=try&revision=4a2e2f7190661614ecddd223dd7178589d0ec5f2
where the results can be viewed in reftest-analyzer.)

We may eventually want to move this or similar tests into WPT, but I'm expecting
more extensive test coverage to be a co-operative effort with the other vendors
who are also implementing support, so this is intended as an interim step just to
ensure we have the basic functionality tested in-tree.

Depends on D154585

Backed out 10 changesets (Bug 1740530) for causing build bustage in COLRFonts.cpp CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=KTfecFyBQu6MtL2uMsXeyg.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=afbcf312dbafdc4d4fb4497128b4e37e24f7009b

Log: https://treeherder.mozilla.org/logviewer?job_id=387485425&repo=autoland&lineNumber=18722

Backout: https://hg.mozilla.org/integration/autoland/rev/9e2e2cf54cc9bfc1770f760651e6587c027b8e1b

Fixed the -Werror=subobject-linkage error; re-landing.

Backed out for causing reftest failures on colrv1.

Push with failures

Failure log
Reftest analyzer

Backout link

Sigh... my try run didn't quite cover all platforms, so we need a small adjustment to fuzz numbers.

https://hg.mozilla.org/mozilla-central/rev/2be4a1d5ac07
https://hg.mozilla.org/mozilla-central/rev/13ae409d093a
https://hg.mozilla.org/mozilla-central/rev/5d1de3ed837b
https://hg.mozilla.org/mozilla-central/rev/4354a0d7248f
https://hg.mozilla.org/mozilla-central/rev/7bacec3b6ce1
https://hg.mozilla.org/mozilla-central/rev/d0a5d11277bb
https://hg.mozilla.org/mozilla-central/rev/bf0dd96b4423
https://hg.mozilla.org/mozilla-central/rev/e1ffdf0a6056
https://hg.mozilla.org/mozilla-central/rev/a5e90bc3b2e1
https://hg.mozilla.org/mozilla-central/rev/a23ef2de9176

FF105 Docs for this can be tracked in https://github.com/mdn/content/issues/20106

Can I please confirm that the way this is used is to specify the @font-face src: descriptor's "tech(...) syntax for an OTF font with gfx.font_rendering.colr_v1.enabed true? So something like:

@font-face {
  font-family: "MyCOLFRv1Font";
  src: url("MyCOLFRv1Font.otf") format(opentype)  tech(color-COLRv1);
}

Specifically, I want to be sure that you can't do this, for example, using https://developer.mozilla.org/en-US/docs/Web/API/FontFace/FontFace or any other way?

It's not necessary to use the tech(...) syntax in order to load a COLRv1 font (any more than it is necessary to provide format(...)). If the colr_v1 pref is enabled, such a font can be used by simply giving its name, e.g.

@font-face {
  font-family: "MyCOLRv1Font";
  src: url("MyCOLRv1Font.otf");
}

or

var f = new FontFace("MyFamilyName", "url(colorfont.otf)");
document.fonts.add(f);

The tech(...) syntax can be used to determine whether a given technology (e.g. COLRv1) is supported, so that the author can provide suitable fallbacks depending on what the browser supports. This applies equally to the src descriptor in a @font-face rule or the source parameter to the FontFace constructor, just like format(...).

So an author could do something like:

@font-face {
  font-family: "MyFancyFont";
  src: url("MyFallbackFont.otf");
  src: url("MyCOLRv1Font.otf") tech(color-COLRv1),
       url("MySVGOTfont.ttf") tech(color-SVG),
       url("MyCOLRv0Font.ttf") tech(color-COLRv0),
       url("MyBitmapfont.ttf") tech(color-CBDT),
       url("MyFallbackFont.otf");
}

to load a fallback if the tech() syntax is not supported, but for browsers that do understand tech(), choose among several different resources depending on the rendering capabilities available.

Thanks Jonathan. FYI, docs for this ended up being an update to browser compatibility to indicate supported in @font-face along with a note about the feature in the MDN experimental features section.
We should revisit more about what this allows when this is no longer behind a preference.