SIF output extension to ship in Inkscape 0.49, needs testing


work on Ubuntu too

so this happen also with your browser?


Yes. The browser is doing exactly what you asked it to, namely to save the page being linked to by the text. The problem is that this page isn’t the actual file: it’s a rendering of the file. (In other words, when you click the link you get an HTML document that has the text of the file, with nice Github formatting). It’s not intuitive, but it works as advertised.


not as advertized, the problem maybe not in the linked page, but in the linking page:

For example the text say “” and the link point to:
but the document that is linked and sent by http server, is not “” like all other web site do.


When you click on the link normally (without doing “Save”), you get a certain github page - and not raw text. What “Save Link As” does is equivalent to clicking on the link with your mouse, and then pressing Ctrl-S on the next page. I’m guessing the reason the document name ends in is so the URL looks clean (other websites would have a lot of PHP stuff in the URL, which makes it very long but at the same time easy to recognize as an HTML page)


In any case it would be good to update the README file to explain the user to use the Download button to get the sources (tarball or zip) or use the raw link on the right top side to get a plain text of the file: …
which can be saved from the browser as the original text ASCII file.


A new stable version is tagged. It contains partial support for blurs and blend methods, as well as better error handling. The readme has also been changed to add a “Download” section.

I haven’t been able to identify the relationship between SVG blur sizes (measured in standard deviations) and Synfig blur sizes (measured in unknown units), so the blurs won’t transfer exactly. This problem been giving me a lot of headaches so I’ve decided to set it aside for now and come back to it after a long break.

All that’s left is to run a final set of tests, this time using Inkscape 0.49 trunk, and then I’m going to move on to other projects. (I’ll still be around to fix bugs and do maintenance - but please speak up if you want something implemented)


Nikitat, would you like me to advertise this plugin? I’m not sure if I want something implemented (at the moment I’m not in the position to “know” what’s to be implemented), although I wonder if the plugin will be available on Inkscape’s next version by default.


I tried the Inkscape SIF exporter out this morning and it is MUCH better than the built in Synfig Studio SVG importer.

The only thing I notice is that Inkscape graphics (including bitmaps) are always slightly too small into Synfig Studio in pixels compared to their size in Inkscape.

Well done for writing this tool, it is fantastic.


DaveJ: can you elaborate on that, and maybe post a few examples to demonstrate? If the pixel size is wrong I want to fix it ASAP.


OK, if I’m doing something for PAL video I’ll often do it at 768x576:

If I export this as a .sif then I get the following file:
2-768x576.sif (29.5 KB)

The Canvas is correctly set up in Synfig Studio as 768 x 576. The graphic is correctly positioned in the top left corner with the top left vertex (Vertex 1) placed at 384px, 288px. However the bottom right vertex of the background (Vertex 3) is placed at -230.400020px, -172.8px when it should be at (384, 288).

Therefore my 768 x 576 SVG graphic becomes approx. 614 x 460.8 pixels in Synfig.

I think that reason is that Inkscape SVG files are 90 dpi. Synfig has imported the graphic as 72 dpi.

90/72 = 1.25 and 768/614 = 1.25.

I hope this is helpful. As I said before I think this Inkscape SIF exporter is fantastic.


Good catch! I’ll work on a fix.


I used the exporter to do the animations in this:

It worked brilliantly - many thanks.


It’s good to know that everything is working for you :smiley:

I’ve though about the resolution problem a bit and it’s not immediately obvious what the “best” solution should be. In fact, there are several options, each with its pros and cons.

1: Create a Synfig animation with the original pixel size, at 90 dpi. This would exactly match the SVG document, but not Synfig’s default resolution of 72dpi. Now suppose you’re importing SVG clipart into an existing Synfig project - then things might not work as expected.

2: Create a Synfig animation with the original pixel size, at 72 dpi. Given that we’re working with vector graphics, this is a lossless dpi downgrade, and the final 72dpi seems more standard (or at least it is what Synfig uses by default). On the other hand, the physical size will be wrong.

3: Create a Synfig animation with the original physical size, at 72 dpi. But if you’re relying on pixel dimensions the result will be very counterintuitive.

Could everyone here please tell me which of these would work best for their use cases?


I would prefer #2. Since Synfig rarely deals wih physical size but pixels I think this option is least disturbing to the user.


I would also prefer #2, as I agree with rylleman it’s the most naturally “expected” behaviour by the user.

Scribus also has this problem importing Inkscape SVG files by the way - in my view the main fault is with Inkscape as it does not allow you to modify the dpi.


Dpi shouldn’t matter when working digital for a digital output, we deal with pixel sizes and this should stay the same in all conversions. Dpi is only relevant when the target is print on paper.


I feel stupid… this is not a problem with doing bad unit conversions - it’s a problem with ignoring the view-box attribute of the SVG. I knew I was ignoring it, but I never thought Inkscape ever set a non-default value.

EDIT: A new version with viewbox support is now online. That should fix the problem.


We should list this tool in


Do you want to edit it by your self? I can make you a redactor account at website. I’ll send you the details of the user by email.


Sure. Please send me the details :slight_smile:

In fact, I just took a look at my mail inbox, I remembered that I had the access right that allows me to edit some context of the site, but I can’t find that mail.