Re: [ft-devel] color framework

[Werner LEMBERG]

>> 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.

>> 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.


    Werner