On Sat, Dec 15, 2018 at 11:10 PM Alexei Podtelezhnikov <apodt...@gmail.com> 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. > 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. 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. > >> 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. > I think you misunderstood my intentions upthread. When I asked what's wrong with current color framework, I really meant it. And when I said as long as cairo and Chrome work I don't care, I also meant it :). All I'm asking is, if FT_LOAD_COLOR is passed to FT_Load_Glyph() then color bitmap be rendered. How it trickles down the abstractions and machinery into render, you can change. Since I brought up FT_Face vs FT_GlyphSlot issue, let me put it in writing: 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! Cheers, b -- behdad http://behdad.org/
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
