My apologies for the delayed response. With respect to support for the rasterization of color glyphs using COLR V0 or V1 when using the FT_Load_Glyph for instance, I do believe this is something that FreeType should support.
I do agree that support for Kern and OpenType tables such as GPOS and GSUB is not something that FreeType should support since this is not rasterization related. It is more specific to text layout. By contrast, rasterization of glyphs regardless of their encoding format should be something that FreeType supports natively. > Right now, the easiest solution is to stick with an older NotoColorEmoji font. I agree but unfortunately Google decided to replace the older version of this font by the newer version using COLR V1 on Google fonts. -----Original Message----- From: Werner LEMBERG <w...@gnu.org> Sent: Wednesday, May 17, 2023 10:49 PM To: step...@unity3d.com; freetype@nongnu.org Subject: Re: COLR V1 Support & FT_Load_Glyph > 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.
