Re: [ft-devel] libsvgtiny (Re: [ft] Three GSoC projects for FreeType)

[suzuki toshiya]

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.
>