freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gradient Color Fonts, COLR v1 Contributions to FreeType


From: Alexei Podtelezhnikov
Subject: Re: Gradient Color Fonts, COLR v1 Contributions to FreeType
Date: Tue, 28 Jul 2020 15:03:25 -0400

Hi Dominik and others

On Fri, Jul 10, 2020 at 7:17 AM Dominik Röttsches <drott@chromium.org> wrote:
> I've made some progress with the COLR v1 extension implementation in
> FreeType and would be happy to hear initial feedback on the general
> approach and API style.

Let me repeat myself by saying that I am not particularly happy with
the current state of COLR support. My main concern is that it does not
attempt to provide users with all data at once. The user is supposed
to get each layer separately. The FT_Render_Glyph implements a special
case blending path instead of calling a renderer to do so. I would
much rather prefer that

1) FT_Load_Glyph sequentially loads and  merges all contours from all
layers into a single outline and uses FT_GlyphSlot->other to tag each
contour with the layer information and the corresponding comprehensive
(including gradient) color description after palette decoding. This
could potentially work for SVG glyphs too. I really want FT_GlyphSlot
to be self-sufficient and ready for a renderer to handle it without
any additional calls. This could be a new glyph format.

2) then FT_Render_Glyph just calls a color renderer which quickly
allocates the entire CBox of memory and just blends the layers
possibly using FT_RASTER_FLAG_DIRECT for speed. We can eventually have
gradient support as well.

Even if Skia/Chromium does not care about the rendering part, FreeType
should and it needs complete immediate glyph description.

> I've added a set of FT_Paint_* / FT_COLR_* structures to freetype.h
> representing the primitives in the COLR v1 Gradients spec here:
> https://github.com/googlefonts/colr-gradients-spec/blob/master/colr-gradients-spec.md

Great.This can and should be stored as FT_GlyphSlot->other array for
each contour / layer defined.

> I've also added two new main entry points:
>
>   FT_EXPORT ( FT_Bool )
>   FT_Get_Color_Glyph_Layer_Gradients ( FT_Face           face,
>                                        FT_UInt           base_glyph,
>                                        FT_UInt           *aglyph_index,
>                                        FT_COLR_Paint *   paint,
>                                        FT_LayerIterator *iterator );
>
> For retrieval of the v1 layers, returning an FT_COLR_Paint union with
> solid, linear or radial gradient information depending on the union's
> format identifier.
>
>   FT_EXPORT ( FT_Bool )
>   FT_Get_Colorline_Stops ( FT_Face               face,
>                            FT_ColorStop *       color_stop,
>                            FT_ColorStopIterator *iterator );
>
> This methods work analogously to the layer retrieval functions for
> COLR v0 and v1, but defines a new ColorStopIterator to retrieve color
> stops of a gradient without requiring large client side allocations.

It is this iterator complexity which I do not like. Why not load
everything into FT_GlyphSlot?

Regards,
Alexei



reply via email to

[Prev in Thread] Current Thread [Next in Thread]