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 <https://github.com/adobe/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 <mpsuz...@hiroshima-u.ac.jp> 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. > > >
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
