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.
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.
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?
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.
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. 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âŚ
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
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.
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.
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? )
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!
I have attempted to implement delayed object loading to my SVG graphics library published under LGPL. It is one day of work including testing, relatively not too much as perpentual explaining why particular SVG file does not work properly. It is practically negligible in comparison with whole extent of LightBurn program.
)