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

[Moazin Khatri]

Dear Toshiya,

You're quite right that my original proposal for this idea was quite different. The idea was to use some external well known and well tested SVG Renderer to render SVG documents and writing the necessary glue code to make this happen. More of it can be found in the proposal.

Writing a new renderer myself sounds something very different than my original plan. I am not saying it's not doable at all, but given my lack of expertise in the area of renderers, its hard to say whether I'll be able to complete it within the GSoC period. However, if somebody volunteers to collaborate with me on this during the period of GSoC, I'd very much love to do that. The volunteer could focus more on the new renderer and I could focus on making it work with FreeType. This would also be something quite similar to my original proposal. :-)

In one of your recent emails in the list you say and I quote:

At present, I don't suggest to link SVG renderer to libfreetype directly.
For sbix color font support, libpng is directly linked to libfreetype,
but I suggest to make libfreetype + SVG renderer collaborate by a callback
system.  

Can you please clarify what do you mean exactly by collaboration via a callback system? With the little knowledge of Software Architecture that I have, my guess is you're trying to say that instead of making FreeType directly dependent on one particular SVG Renderer, we should instead create an abstraction in between so the users of FreeType can plug in any SVG Renderer they like as long as they make it conform to the interface. This would be similar to how Adobe's SVG Native Viewer  relies on a rendering port to render stuff, and the users can plug in any renderer they like as long as they write the glue code necessary. Which you've also done with your Cairo based rendering port. I know how abstractions like these can be written in C++ via the use of Virtual Functions. But I am not sure how collaboration by callbacks work or even if it's the same idea. I apologize in advance if I have got some bit, or all of it wrong. Please explain if you can. It'd be also great if you can point me to any articles, documents, books or videos that explain this technique or codebases that implement this type of a "collaboration by callback functions" technique. 

Thanks,

Moazin

On Thu, May 9, 2019 at 5:54 AM suzuki toshiya <address@hidden> wrote:

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