Re: [ft-devel] color framework

[Alexei Podtelezhnikov]

On Sat, Dec 15, 2018 at 2:55 PM Behdad Esfahbod <address@hidden> wrote:

>> It is wrong to use
>> FT_LOAD_COLOR in FT_Render_Glyph. There is a way to properly pass all
>> necessary information.to that function.
>
> I understand your desire to encode all info into FT_Outline; but given how 
> much glyphslot is tied to face, I don't think it's a big deal to require face 
> and load layers at render time.

Exactly. Besides FT_GlyphSlot, there is FT_Glyph completely detached
from FT_Face. Those are rendered with FT_Glyph_To_Bitmap, which calls
FT_Render_Glyph_Internal with dummy FT_Face and unaware of
FT_LOAD_COLOR. This works because FT_Render_Glyph does not (did not)
use to dig though FT_Face. Indeed the rendering used to be completely
separate from loading.

FreeType is about to make a major leap into color rendering. 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.

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

Alexei