Rendering support for COLRv1 fonts
Categories
(Core :: Graphics: Text, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox105 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
References
Details
(Keywords: dev-doc-complete)
Attachments
(10 files, 13 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
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.
Updated•3 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
Assignee | ||
Comment 3•2 years ago
|
||
Depends on D152036
Assignee | ||
Comment 4•2 years ago
|
||
Depends on D152037
Assignee | ||
Comment 5•2 years ago
|
||
Depends on D152038
Assignee | ||
Comment 6•2 years ago
|
||
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.
Assignee | ||
Comment 7•2 years ago
|
||
Depends on D152041
Assignee | ||
Comment 8•2 years ago
|
||
(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
Assignee | ||
Comment 9•2 years ago
|
||
Depends on D153076
Assignee | ||
Comment 10•2 years ago
|
||
Depends on D153077
Comment 11•2 years ago
|
||
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?
Assignee | ||
Comment 12•2 years ago
|
||
(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.
Assignee | ||
Comment 13•2 years ago
|
||
Depends on D152038
Assignee | ||
Comment 14•2 years ago
|
||
Depends on D153078
Assignee | ||
Comment 15•2 years ago
|
||
Depends on D153871
Assignee | ||
Comment 16•2 years ago
|
||
Depends on D153872
Assignee | ||
Comment 17•2 years ago
|
||
Depends on D153873
Assignee | ||
Comment 18•2 years ago
|
||
Depends on D153874
Assignee | ||
Comment 19•2 years ago
|
||
Depends on D153875
Assignee | ||
Comment 20•2 years ago
|
||
Depends on D153876
Assignee | ||
Comment 21•2 years ago
|
||
Depends on D153877
Assignee | ||
Comment 22•2 years ago
|
||
Depends on D153878
Assignee | ||
Comment 23•2 years ago
|
||
Depends on D153879
Assignee | ||
Comment 24•2 years ago
|
||
Depends on D153880
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 25•2 years ago
|
||
Assignee | ||
Comment 26•2 years ago
|
||
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
Assignee | ||
Comment 27•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 28•2 years ago
|
||
Comment 29•2 years ago
|
||
Backed out 10 changesets (Bug 1740530) for causing build bustage in COLRFonts.cpp CLOSED TREE
Log: https://treeherder.mozilla.org/logviewer?job_id=387485425&repo=autoland&lineNumber=18722
Backout: https://hg.mozilla.org/integration/autoland/rev/9e2e2cf54cc9bfc1770f760651e6587c027b8e1b
Assignee | ||
Comment 30•2 years ago
|
||
Fixed the -Werror=subobject-linkage
error; re-landing.
Comment 31•2 years ago
|
||
Comment 32•2 years ago
|
||
Backed out for causing reftest failures on colrv1.
Assignee | ||
Comment 33•2 years ago
|
||
Sigh... my try run didn't quite cover all platforms, so we need a small adjustment to fuzz numbers.
Comment 34•2 years ago
|
||
Comment 35•2 years ago
|
||
bugherder |
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
Assignee | ||
Updated•2 years ago
|
Comment 36•2 years ago
|
||
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?
Assignee | ||
Comment 37•2 years ago
•
|
||
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.
Comment 38•2 years ago
|
||
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.
Description
•