> > I would much rather prefer that > > > > 1) FT_Load_Glyph sequentially loads and merges all contours from all > > layers into a single outline and uses FT_GlyphSlot->other to tag > > each contour with the layer information and the corresponding > > comprehensive (including gradient) color description after > > palette decoding. This could potentially work for SVG glyphs > > too. I really want FT_GlyphSlot to be self-sufficient and ready > > for a renderer to handle it without any additional calls. This > > could be a new glyph format. > > > > 2) then FT_Render_Glyph just calls a color renderer which quickly > > allocates the entire CBox of memory and just blends the layers > > possibly using FT_RASTER_FLAG_DIRECT for speed. We can > > eventually have gradient support as well. > > Alexei, this sounds interesting. Care to implement this, as an > alternative interface? What Dominik has written fits quite well to > the existing API, so I'm in favor to add his code.
I am scared of ttgload.c, which constantly juggles transforming and hinting. Are layers ever transformed or hinted?.. > Note that the iterative API works also quite nicely if you are *not* > using FreeType to manage gradients and the like. On the other hand, > it seems to me that your proposed solution necessitates gradient > handling within FreeType (but maybe I'm just confused). On the contrary, I am advocating for loading of all layers as combined outlines with attached color descriptors per each contour or blocks of contours, but short of rendering. Rendering them would be implemented *eventually* but not necessarily for all cases. I see that solid colors and linear gradients are within the realm of possibility for FreeType as they do not require non-linear math. Alexei
