Dear Moazin, Alexei, In my understanding, Sylvain's idea is much different from the draft schedule of GSoC project of Moazin: I think Moazin was going to combine some well-known & tested existing SVG renderer, not going to write yet another SVG renderer. Doing it might require big change of the schedule and task list in GSoC.
I welcome if there's any volunteer to work in this direction (if Sylvain would do, that's very helpful for Moazin), but I don't recommend Moazin to do it. Moazin, how do you think about? Alexei, do you think whether it could be achieved (as a subside task) within GSoC 2019 period? Regards, mpsuzuki Alexei Podtelezhnikov wrote: > That said, I am wondering if the expressive power of freetype internal vector > code could satisfy the requirements of the font svg rendering. Because that > would reduce the external dependency to some xml parser, then some internal > freetype code would "translate" this font svg directly into internal freetype > vector code. > > FreeType historically was a colorless rasterizer and only returned a pixel > coverage map, which could then be colored and blended by a client > application. As of the last version, FreeType can now add color according to > CPAL/COLR tables, where each layer is blended with a monocolor. To support > SVG, tt is a matter of implementing color gradients, which is not that hard. > Some work needs to be done to implement data structures for complex colors > and properly isolate the blending code into a dedicated blender-rasterizer. > _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
