On Sat, Dec 15, 2018 at 2:55 PM Behdad Esfahbod 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
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
