Issues with SVG importation

For most of my vector designs (except test files), I draw in Inkscape, then I import the result in LightBurn (v. 1.13.01 for now), either from the SVG file, or by copy / paste.
I will use the terminology of Inkscape, things might be named differently in other softwares like Illustrator, CorelDraw or Affinity Designer, for example.

I have found some quirks, some already known, some perhaps not. I would like to list them in this thread. It might be useful to people finding the same issues, the problems are, somehow, spread in several threads about more specific issues.

Maybe someday the LightBurn developers will address some of these issues. I know that parsing and interpreting SVG data is very complex, so there is no urge.

I will put one issue per message, for easier reference.

Clones

An issue I have seen in several thread is about clones.

Let say you made a shape you want repeated in your design.
You can duplicate it, you will have n copy in your project. But if you need to alter the shape, slightly move a node, adjust a curve, you will have to delete all copies and do it again.
Alternatively, you can make a clone. In Inkscape, select the shape and do Edit > Clone > Create Clone. Then move the clone elsewhere.
The clone has interesting properties: you can resize it. If you resize the original, the clone(s) will be resized proportionnaly.
You can rotate the clone. Rotations of the original leave the clones unaffected.
If you edit the shape, changes will be reflected on the clones.
You can apply fill and stroke styles on a clone, but they won’t be changed, unless you unset them (the ? icon) on the original.

In practice, the orignal share is, say, a <path> element, with an id given by Inkscape, say “path514”. The clones are <use> elements, with an xlink:href="#path514" which is the part referring to the orignal shape. It might have additional properties: likely a transform matrix to move and rotate (and even skew) the shape, a style (with above restrictions, and perhaps not relevant for LB), and x and y properties, always set to 0 by Inkscape (which use transform instead) but they might be set by other softwares.

Currently, LightBurn doesn’t take in account these clones, they are just ignored. An easy workaround is to unclone them: Edit > Clone > Unlink Clone after selecting them. Save the file under a different name or place, as you might want to keep the version with clones if you need to edit the original.

I believe it isn’t very hard to implement support for these clones / use, at least in simple cases. I hope it would be done someday.

[EDIT]: It is already in the suggestions: Support for SVG <use> elements · LightBurn
I attach here a sample of SVG with clones for reference for this suggestion.
Rosace gravure - pure

display:none

In Inkscape, you can hide elements by click on the eye in the layers view, or right-click Hide Selected Objects.
It is useful if you made construction objects, guidelines, etc. and what to hide them to see the final result.

Inkscape hide them by setting the style display:none on it. Other softwares might add an attribute display="none" instead.

LightBurn doesn’t take this in account, and all elements are displayed. It would be nice to have them ignored in the import process, no?

[EDIT]: Corresponding thread in the suggestions site: Add an "Ignore hidden layers in SVG" option · LightBurn

Hi Phillipe,

Inkscape have their own custom type of SVG file, which doesn’t obey the standard rules of SVG files. It allows them to add their own fucntionality, but it means that things don’t import from Inkscape into other software as well by default.

However, Inkscape allows you to get around a lot of this, by saving it as a ‘plain’ SVG.

If you go file>save as and change the file type to “plain” SVG, and save a copy of your file, is that importing into LightBurn as you would hope?

If not, I would try converting all objects to paths, then saving as a plain SVG, and then importing into LightBurn.

With regard to supporting the functions your describe natively in LightBurn, have you made a suggestion via our Feature Suggestions? That’s the best way to get your ideas in front of the devs. :slight_smile:

I disagree with you on the first point: Inkscape outputs a standard SVG, with regards to the specification. They have extensions, declared following XML rules, that are not needed for rendering, and are ignored by other softwares. Saving to plain SVG gets rid of these extensions (additional hints for further editing, like viewport or grid) but shouldn’t solve issues.

The two first issues are about standard SVG, and indeed should go to the suggestions page, I thought suggestions here would count. :slight_smile: And the thread is also here to help people with similar problems.

Indeed, removing the unwanted, hidden parts, converting texts to paths and unlinking clones are good workarounds, that’s why I mentioned them. Being able to avoid these steps would be better, if possible.
I will suggest them, although I guess it has been done in the past.

[EDIT]: I upvoted the suggestions I gave in references to my remarks. If these problems are annoying you, upvote them too! The annoying part is that apparently the login on this site is different from the one on the forum which is different from the one on the commercial site of LB…

Thank you.

For now, the easiest way that I found was to export a PDF file from Inkscape, and “Convert text to paths”. This will explode all of the clones, and will not export the “hidden” objects. Saving as plain SVG did not fix the problem with clones.

It can be a shortcut, indeed. Otherwise, as said, you can select everything and unlink the clones (possibly in a recursive way if needed), remove the hidden objects / layers, then save to another name (to avoid losing these cool features in your work document).
For the hidden objects / layers, sometime I just copy everything then paste in LB: Inkscape doesn’t copy the hidden parts.

I hate how SVG works sometimes - it’s extremely flexible in ways that make importing the files very difficult.

Your example defines the used shapes after they are used. This means I have to buffer these up until I find the actual definition, and that is just much harder than it needs to be.

This file also doesn’t define the path to be cloned in the ‘defs’ section of the file, which is typically where I’ve seen this before, so I’ll have to update our handling to allow any shape in the file to be re-used, which is, again, going to add a lot of complexity to the importer.

1 Like

I see what you mean. I admit I didn’t look at the structure before.
Indeed, a shape can be part of the drawing AND referenced for cloning, I suppose that’s how we do it in Inkscape: we first draw the shape, then clone it. I suppose Inkscape could clean that when saving it, but you can’t expect every software to behave nicely, alas.
You seem to do a streaming parsing, which can makes sense as some SVG images can be very heavy, so this method saves memory, I suppose.
BTW, I recently discovered that xlink:href is deprecated (SVG 2) in favor of the simpler href, so you have to handle both syntaxes…
Yes, SVG is a very complex standard, writing a good parser / tokeniser for it must be a huge task.

Well, you can mark the suggestion as “won’t do” and list the limitations of the import somewhere. After all, there are workarounds: as suggested, we can unclone everything, or export to PDF.

I hope that this is a standard for now. XML library usually reads whole XML to internal structures and program iterates these internal structures.

Linear parsing XML is much more faster, but developpers preffer big and fat libraries.

No, only bad developers. :slight_smile:

Basing SVG on HTML makes it extremely flexible, but that flexibility makes it incredibly difficult to support. We use a streaming parser, because it uses MUCH less memory and has significantly lower complexity, but it also makes supporting some things more difficult than they would be if we buffered the entire file.

Anyway, changing the SVG parser to a buffering one would be a major, breaking change (probably), not sure it is worth it (or for LB 2.0? :yum:)

Another difficulty with clone / use is that we can clone clones (I do that as I just take the nearest shape around, not always the original one), so finding the original drawing to render would need to build a tree of references!