>> 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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel