> In version 2.13.0, is FT_Load_Glyph supposed to be able to load > color glyphs using the COLR V1 format?
No, it isn't. We have an ongoing discussion on that (and related issues) at https://gitlab.freedesktop.org/freetype/freetype/-/issues/1229 Please chime in if you like. > If no, are there plans to add such support or are we expected to > manually handle such cases? The thing is that the current COLR v0 support is only experimental. Actually, it doesn't belong into FreeType proper and is just a courtesy to the user, covering only the simplest case. Compare this to the 'kern' table, which FreeType supports with an API, but most recent fonts switched to the more versatile 'GPOS' kerning, which FreeType cannot handle (and never will).[*] COLR v1 support is like 'GPOS' handling: It is too complicated (or rather, too high-level) to be integrated. However, if someone steps forward, taking, say, the Skia code to handle COLR v1, and converting it into a small library, we could add hooks to FreeType similar to SVG support. This might actually be a nice GSoC project... > For reference, I am able to load color glyphs using an older > version of the NotoColorEmoji font but not from the latest > release of this font from Google which uses the COLR v1 format. > By loading I am again referring to using FT_Load_Glyph. Right now, the easiest solution is to stick with an older NotoColorEmoji font. Werner [*] Some ancient versions of FreeType actually *could* handle GSUB and GPOS to a certain extent, but this was removed for good reasons, eventually leading to the creation of the HarfBuzz library.
