On Sat, Dec 15, 2018 at 2:55 PM Behdad Esfahbod <beh...@behdad.org> 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
