Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

[Alexei Podtelezhnikov]

> > 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.
>
> Alexei, this sounds interesting.  Care to implement this, as an
> alternative interface?  What Dominik has written fits quite well to
> the existing API, so I'm in favor to add his code.

I am scared of ttgload.c, which constantly juggles transforming and
hinting. Are layers ever transformed or hinted?..

> Note that the iterative API works also quite nicely if you are *not*
> using FreeType to manage gradients and the like.  On the other hand,
> it seems to me that your proposed solution necessitates gradient
> handling within FreeType (but maybe I'm just confused).

On the contrary, I am advocating for loading of all layers as combined
outlines with attached color descriptors per each contour or blocks of
contours, but short of rendering. Rendering them would be implemented
*eventually* but not necessarily for all cases. I see that solid
colors and linear gradients are within the realm of possibility for
FreeType as they do not require non-linear math.

Alexei