SVG Import fails via drag 'n' drop

This happens with File -> Import too. It seems that Inkscape loses the contents of the second 'defs' element.

Can this be isolated to a single platform? Win32? Linux? Mac? Other?

I tested File -> Import on Windows XP. But I'm sure the bug would apply on all platforms, as it doesn't look like something that would be Windows-specific: the SVG import isn't designed to handle multiple 'defs' elements (and it loses 'style' elements too: bug 196898).

I think drag and drop acts exactly like import, because you are dragging the contents of the file into the present document. Import *has to* ignore some of the stuff in the document, like the page boundaries (bounding box?) because otherwise it would not function as an element of the existing page the document is being imported into.

It seems that whatever information is intentionally being ignored is also causing problems.

There have also been two bugs that are in a very small way related to this, as opening a PDF file would result in either upside down elements in the picture (one bug) or upside down text boxes started subseuently (another bug). But definitely in the second case, importing the PDF did away with any problems with upside down elements.

So if we can nail down exactly what is being ignored, and how that relates to your road, then that will help.

The best thing to do is to delete elements from the picture one by one (saving different versions each time) until you get a version that does it and then a verion that doesn't, and post both of them. This is about finding the simplest test case, which will narrow down the possibilities of what needs to be fixed. Someone may know how to fix it (I don't).

Here's a simpler test file.

If you open this file in Inkscape, you'll see that there are three squares with gradients.

But if you import the file, you'll only see the first square. The other two squares are still there, but they don't render because they are filled with gradients that failed to get imported. The gradient that was imported successfully was in the first 'defs' elements, while the other two were in the second and third and 'defs' elements.

If you edit the file in a text editor to combine the 3 'defs' elements into 1, then the file imports OK. So the problem is as I suggested before - when importing, Inkscape ignores all but the first 'defs' element in the file.

In fact, it's only at the top level (children of the root element) that 'defs' elements are ignored. A 'defs' element further down the tree will be imported (though in a different manner than the first top-level one).

Here's a patch to stop Inkscape ignoring top-level 'defs' elements when importing. With this patch, all top-level 'defs' elements are handled in the same way as the first one is currently handled, and both test files therefore import correctly (via drag-and-drop or File->Import).

Howeover, there are still many problems with SVG import, and the whole concept really needs to be properly thought out. The current implementation makes no attempt to deal with any of the difficult issues, and my patch doesn't change that.

This patch has been included in a more comprehensive svg import patch at LP #227472, and that patch fixes the problem on win32 trunk.

The patch has been applied to trunk with other related patches at SVN revision 18579. See LP #227472 for more info.

This bug was fixed in the package inkscape - 0.46-5ubuntu2

---------------
inkscape (0.46-5ubuntu2) jaunty; urgency=low

  * Add 100_svg_import_improvements.dpatch:
    - 'style' elements at the top level are not lost on import
      (LP: #196898)
    - Contents of top-level 'defs' elements are not lost on import
      (LP: #209296)
    - layers are unlocked when they are converted to ordinary groups
      (LP: #221888)
  * Add 101_gtk_marshal.dpatch: Fix build errors against gtk+-2.13.x
    (LP: #238217)

 -- Bryce Harrington <email address hidden> Tue, 07 Apr 2009 22:32:31 -0700