RE: COLR V1 Support & FT_Load_Glyph

[stephan]

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 <wl@gnu.org> 
Sent: Wednesday, May 17, 2023 10:49 PM
To: stephan@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.