The CBDT/CBLC bitmap color emoji font is still available at https://github.com/googlefonts/noto-emoji/tree/main/fonts/NotoColorEmoji.ttf and is being kept up to date
On Tue, 6 Jun 2023, 21:15 , <step...@unity3d.com> wrote: > 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. > > >
