On Tue, Dec 18, 2018 at 5:35 AM Werner LEMBERG <w...@gnu.org> wrote: > > >> 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. >
FreeType has been rendering color fonts on over a billion devices since 2015 or so. I still think the whatever FreeType is adding now is minor in comparison to that. At any rate, doesn't matter. > >> 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. > Obviously. What's wrong with defining new API? -- behdad http://behdad.org/
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
