>> 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.
You completely misunderstood. Alexei talks about FreeType, not about
the latest font news.
FreeType has been rendering color fonts on over a billion devices since 2015 or so. I still think the whatever FreeType is adding now is minor in comparison to that. At any rate, doesn't matter.
>> 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.
We won't do SVG. However, having a good representation of contours
with color layers is quite useful.
> 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.
Let's see whether someone is interested in this. What about making
Add SVG support
a GSoC project? :-)
>> > 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.
`FT_Glyph' is not, but Alexei wants to improve `FT_OutlineGlyph'.
> 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!
AFAICS, this can't be fixed. The only solution I see is to define a
new API.
Obviously. What's wrong with defining new API?
--