Joining effort / merging code with inkscape ?

Have you ever considered joining your efforts with the inkscape development team ?

This question may sound strange, but the inkscape development roadmap shows that animation features are planned for next releases (basic animation support for release 0.48 and full implementation for 0.49). The svg specification itself, version 1.1, describes animation features, that are not implemented yet by any software : see

Even if synfig and inkscape are different, they have some concepts and development properties in common, and each one would benefit from the other’s “specialty”. As a vector graphics editor, inkscape is IMHO better than synfig and has become a “standard” among open source programs. On the other side, synfig development team has experience in animation software, which would benefit inkscape, but it is also (probably) smaller than inkscape’s team, and thus could benefit from its integration into a bigger project.

There’s already some interoperability between synfig and inkscape file formats, since synfig can (at least partly) import svg files created with inkscape. Both projects are also built on the same graphical interface library (gtkmm), so I guess it would be possible to integrate parts of synfigstudio’s user interface (eg. the keyframe panel) into inkscape without rewriting the whole code.

Anyway, I think that merging code between these two FOSS projects could result in a wonderful software.

For me, file formats are the crux of the issue. The SVG standard is, in my opinion, very poorly suited for animation. Inkscape’s goal is complete implementation of that standard. That prevents any merging of the two application in their entirety.

That is not to say we can’t share code. I would very much like to have common renderer and vector math libraries. Sharing UI code is also reasonably feasible. But in order to make any of these changes, we need to get community approval and at least one inkscape/cairo/lib2geom developer involved.

Genete: is there any particular reason why you decided porting the renderer to OpenGL vs cairo?

I didn’t decide anything. One day a guy (Uiomae) wanted to write a renderer for Synfig using the OpenGL renderer to speed up the synfig render engine and he started to code. Other day he leaved and let it unfinished. That’s the story. If anyone want to implement a renderer (Cairo or other) in Synfig he’s free to do it.

Regarding to Inkscape merge I think that there are some other problems to solve better rather than try to merge into Inkscape. Too many conceptual differences to solve between Inkscape and Synfig for a very limited Synfig coding team. I don’t know Inkscape internals but I know some of the internals of Synfig and I bet that it would loose lots of features in favour of the Inkscape native format (SVG) if we merge projects. And exactly those features are the ones that makes Synfig unique (noise distort, noise gradient, and the way some filters work for example)


Sorry, I misunderstood. I thought you were somehow involved in that.

I was not aware of that. That’s definitely a reason to keep a separate development line from inkscape.

Just because Inkscape and Synfig share the same conceptual basis and some (limited!) file compatibility does not mean that the actual software of the two programs can be combined nor that it would make sense to do so. Combining software in an efficient and effective way is one of the hardest problems in computer science. It would most likely take less effort for them to add various forms of animation to Inkscape, or for us to improve the Synfigstudio GUI.

I don’t think so. If I remember correctly, Inkscape uses straight gtk+ without using gtkmm layer.

A conceptual cross (having the best of both worlds) might be desirable. Combining the two codebases is, however, not the best way get there.


According to inkscape’s website and my distribution package management system, inkscape is (at least partly) written in c++ and built with gtkmm.
But for the rest of your post, I think you’re right and that my question was naive.