FreeType is about to make a major leap into color rendering.
Is it? Color rendering was the news before variable-fonts were news. So 2013. The world has moved on.
It is
possible to make it right while keeping rendering separate. The
current solution is way to specific to COLR/CPAL. What if CFF comes up
with something different? I agree that current FT_Color is too simple.
We can add an index field there to indicate layers explicitly or even
reference gradient colors of SVG fonts.
You cannot take just outline and gradients out of SVG and shove it into a model you design now. It's either SVG, or plain outlines. Don't try representing SVG in some other form unless you are volunteering to do it all.
I actually found the FT_Renderer abstraction useful to let toolkits / applications install an SVG renderer on an FT_Library to render SVG color fonts. I like to see that as a possibility.
>> The choice is between a hack and a proper implementation.
>
> Not really. It's not like glyphslot and face can be used separately. That's, in fact, the biggest problem with FreeType API: that one cannot use FT_Face from multiple threads at the same time, because all uses of it use the embedded glyphslot.
Full circle: is FT_Glyph or rather FT_OutlineGlyph, extracted and
detached by FT_Get_Glyph, of any use? It is stripped down to bare
bones though.
Thank you for your understanding of my position. Really.
I think you misunderstood my intentions upthread. When I asked what's wrong with current color framework, I really meant it. And when I said as long as cairo and Chrome work I don't care, I also meant it :). All I'm asking is, if FT_LOAD_COLOR is passed to FT_Load_Glyph() then color bitmap be rendered. How it trickles down the abstractions and machinery into render, you can change.
Since I brought up FT_Face vs FT_GlyphSlot issue, let me put it in writing:
It would be so much easier for FreeType clients, specially toolkits and frameworks, if FT_Face, FT_Size, and FT_GlyphSlot were all separate. Ie. one FT_Face could be used with multiple FT_Size's simultaneously, and multiple FT_Face/FT_Size pairs could be used to load glyphs into different FT_GlyphSlot's simultaneously.
That is, for example, similar to how hb_face_t, hb_font_t, and hb_buffer_t are modeled. FreeType goes most of the way there, but alas, ties one FT_GlyphSlot and one FT_Size into the FT_Face, making it totally unusable for any sophisticated sharing scenario. If you can fix *that*, I'd be indebted to you eternally!
Cheers,
b