In short; the new Inkscape 0.92 can't read SVG made with previous Inkscape versions without breaking them visually.

For a professional like me using Free/Libre Open-Sources Software, it means: if a client, a publisher, a contributor or a translator tries to open today one of the 10,804 available source SVG files on Pepper&Carrot with the new Inkscape 0.92, he'll get rendering issues with text and will blame my competences as a professional for either making bad work or using unreliable tools.

Should 10K artwork not be interpreted correctly anymore after an update?

Should I be blamed as an artist for the tools I'm using? For... using FLOSS?

How can I invest my time and that of my contributors on Pepper&Carrot if this type of thing happens with the tools I'm using?

The line-height breaks every speech-bubbles in 0.92 it affects hundreds of pages in 40 languages and also all previous revisions on git... with local, online, all in all ...10,804 files!

No answers or professional solutions

I wasted hours to investigate how this type of major issue could land into a major release. I found over 5 duplicates bug-reports ticket about it (even during the testing period) and nowhere can I read that this issue was considered as a serious, high-priority, release bug. On all the reports, an external Inkscape extension is suggested to fix your previous SVG files one by one. Also, now a dialog box will pop-up when you open a previous Inkscape SVG to choose between two obscure choice. Read it, let me know if you can choose an option:



Screenshot of the new dialog for all SVG before Inkscape 0.92.

So: "Set 'viewbox'" or "Scale elements" ?

More work for the users

I can't spend the rest of the month to convert over 10,000 files manually one by one and push them to Git. I don't want to lose all the previous revisions of SVG file on Pepper&Carrot either! And what if I even do it ; will Inkscape tell me I have to do it again with Inkscape 0.93? This type of development decision, relying on 'users must fix it themselves' must stop. I hate when I have to admit that using open-source is actually a production handicap in this type of scenario. So, first, let accept it: 0.92 is a released version. Not a beta, not an alpha. No. It's released as a major. stable. version. This version will hit all the GNU/Linux distros, Windows and Mac users will download this new version from the official website and problems with SVG files will hit Pepper&Carrot. Downgrading my local install to 0.91, blacklisting 0.92 SVG files on the renderfarm and advising all 40 translators to not update to 0.92 is a short-term fix and not a pleasant one.

A graphical difference with Meld between a Inkscape 0.91 SVG on left, and a 0.92 on right.

Bugs can happen

I hope this type of blog-post will shake the mindset a bit, and make developers more serious about compatibility. The users shouldn't be prompted with a dialog with jargon. The artwork or rendering shouldn't be broken. Inkscape should do the auto-conversion to keep the artwork as it was (especially because the software can). Isn't it the task of Inkscape to be able to read SVG? to properly read itself? I hope a version 0.92.x will happens and solve this serious bug [1] . For those who have been following my work for the last ten years, I like to promote the release of new Free/Libre and Open-Sources Software versions. It costs me a lot emotionally and in production-time to have to make this type of blog-post against a project I love. But what else can I do?

And you, will you fix all your previous SVG manually?

... Downgrade to 0.91?

... Explain to your clients all your SVG sources before 0.92 can be broken?

Help me to express yourself, share, spread the word to send a signal that this is not the type of bugs that can land in a released software! Also, users of Inkscape needs to know what 0.92 might do to their SVG files. Inkscape deserves better than this!

Notes and updates:

Note: The story continues here in the main bug report now

Update: (same day at night) I spent the evening on the Inkscape-devel channel, and thanks to the hard work of the developers Mc and Su_v ; things are evolving in a good way. They had proof-of-concept of what could be done automatically in future 0.92.2 ( too late for 92.1 ) : The result is not pixel-perfect, but it's near. Really near. ( imagemagick compare was used to make diff ) It's so near it's hardly perceptible for a trained human eye. This seems to be going well. They have a plan to make Inkscape take the 'best decision' to convert the file, based on whether the SVG file comes from version 0.48 to 0.91, and only prompt user with a more detailed dialog when the choice is really controversial. I have good hope this will lead to a 0.92 or 0.93 that is compatible with previous Inkscape SVG files.

Update2: ( During week-end ): I took the time to reply comments here and on Reddit/r/linux [2].

Update3: ( On monday) I compiled a branch of Inkscape [3] ( taking the time to learn how to compile Inkscape, grab the dependencies on Arch, handle Bzr, launchpad ; thanks Mc for the help!). I could test this branch on a big variety of SVG files. Almost all files were working correcly ; in rendering CLI mode worked. Fixing this bug is in really good way, thanks to the big big work of Mc and the advices of Su_v. They worked hard during week-end to fix this issue. This is beyond all my expectations and I feel confident for the future of Inkscape 0.92.x . This issue also revealed a lot of organizational issues in Inkscape management and pushed the team to fix them ( bug priority, etc..) [4] .

Update4: ( Almost after a week): Thanks to the hard work of the Inkscape team the next 0.92.1 will ship the auto-fixed compatibility. 0.92.1 is actually frozen in a 'pre0' period for a little week ( I'm testing it ) and will be released after this test period. 0.92.2 will probably embed a smarter solution to propose a better dialog for the dpi change.

Links and references: