Synfig: Native svg support; deprecate sif; seperate compositing

[alyssarosenzweig]

At present, Synfig uses the sif file format for all data storage, ranging from vector graphics to animation parameters to metadata. The sif format is sparsely documented and, besides Synfig itself, has almost no ecosystem surrounding it. Primitive converters to other file formats, notably svg2sif bundled with Inkscape, do exist, but these are one-way and only support a fraction of either format's capabilities. Meanwhile, Synfig itself does not have working svg support (import is broken and export is nonexistant).

This is not a theoretical concern. Putting aside relative technical merits of various file formats, as a result of the sif format, Synfig is not interoperable with other vector editors. We do support bitmap workflows like those based on cut-out animation, but vector work is exceedingly difficult. There is limited vector editing supported, but it is cumbersome and missing essential features compared to mature dedicated editors, such as Inkscape.

Meanwhile, the Synfig codebase is large, growing, and insufficiently maintained. While it is the (subjectively) the best libre program for animation, it bundles a great deal of frequently broken or unstable functionality, even where superior free replacments exist. One major example is the vector compositing suite, whose UI suggests it was patched on as an after thought.

There is a solution: make Synfig standards compliant. Rather than using our sif format, a de facto walled garden, Synfig should natively work in svg. It is okay if there are Synfig-specific extensions to the svg format; indeed, it may be wise to avoid native svg animation support. But at a minimum, vectors need to be native svg, and Synfig must preserve features in the format that it does not yet understand. This way, an artist has the freedom to work in any vector editing they choose. Personally, I would advocate for the use of Inkscape, as it is featureful and free, but in principle any compliant svg editor would work, including proprietary ones, which would accelerate Synfig's adoption. Further, the svg could be animated in Synfig but still later modified in the original vector editor, preserving animation, which is necessary for certain workflows and tremendously useful for others. (It would be useful to pair this with file linking, so artists could design animation ready characters without touching the main animation project.)

With these changes introduced, the sif file format would be supersed by native svg or other standardised formats. Support for loading and converting sifs should be preserved, for legacy projects to migrate, and for the interim transition period, saving support could exist as well. But in general, once implemented, sifs should be deprecated.

Additionally, once vector composition can occur in other applications, the much of the support needed for this feature could be removed from Synfig. There is a some overlap between features needed for composition versus animation; basic editing capability, like the ability to manipulate Bezier paths, must be preserved. Still, a substantial amount of code could be removed without Synfig compromising what it does best: animation.

As an aside, as some Synfig users may like this interface, Synfig could be forked as a purely composition focused application. I am not interested in this personally, but it is free software, and if this would help the adoption of native svg support, I would support it. Indeed, if forked after native svg support is implemented, the compositon editor would be standards compliant as well!

What is the roadmap for implementing this? Slowly. While it is critical, in my opinion, to the project's overall well-being, this is not a trivial task. It may be of interest to share code with related projects, like Inkscape, to avoid the drudgery of implementing svg support to begin with. That would also have some side benefits with respect to filter support and such, although compatibility with the essential feature set is the priority.

It is possible that, due to the magnitude of this change, a fork may be necessary. I am prepared to accept this possibility, and if this is the case, I may be interested in forking for this purpose. Still, I sincerely hope that upstream is interested in moving in this direction (even if its implemention is a long way out). I beg you to put aside subjective qualms and attachment to Synfig's status quo; given the state of our ecosystem versus that of proprietary animation programs, this is a necessary change for the sake of libre animation.

Discussion welcome :)

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Blaggejoe]

+1 (Inkscape user Ralf)

[libreartist]

I respect your motive. Both SVG and .sif formats are XML compliant, yet SVG is an open standard and .sif is not standardised so far. Both SVG and .sif support raster graphics (.png) inside them and they support (different implementations of) vector animation. While .sif implements raster animation with bones and skeleton, SVG does not do raster animation. So, what could be done (improved upon bobbybee's suggestion) are:
1) .sif format to have all of its vector components registered as SVG, so that there will be a possibility of 'vector only' export of SVG components, be edited in Inkscape, and later be imported into same Synfig scene later.
2) I don't want to call the deprecation of .sif format, because it defines the internal workings of the entire Synfig. Switching over to SVG as native format for the entirety would lose all of the raster operations. So, what could be done is STANDARDISING .SIF as open format (with proper roadmaps and regular updates, synchronous with the roadmap and updates of Synfig ).
3)I would be cool and efficient to see .SIF as wrapper of SVG and PNG inside, with (already implemented) descriptions of raster animation and (SVG standard) vector animation. And, .SIF remains XML-based (editable in normal text editors) format.