Re: COLR V1 Support & FT_Load_Glyph

[Cosimo Lupo]

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 , <stephan@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 <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.
>
>
>