Lightburn importing colors all wrong from inkscape

[combatwombat42 (sam)]

I have an SVG file that I edited in inkscape 1.2.2, it looks like:

I have uploaded it to Dymaxion map individual tiles by combatwombat42 - Thingiverse and it renders perfectly in internet explorer:

but when I import it into lightburn, the colors of everything are completly wrong

look at the west coast of south america, the circles on basically every tile, mexico,and the south pacific, it seems like lightburn is basically randomly choosing colors. What is going on here?

[berainlb (PY)]

Looks like those shapes are made up of disjointed line segments. And possibly multiple overlapping lines?

Did you map the RBG colors from LightBurn to Inkscape when selecting colors?

Treating top-level elements of imported SVG as separate layers

This can be done by changing the color of the shapes. LightBurn will attempt to map the color defined in the SVG to the closest layer in LightBurn. Matching the RGB color from LightBurn precisely is your best bet. You can get a reference for the layers between these two posts:

[combatwombat42 (sam)]

I used this palette Color palette for Inkscape for my colors and each path in the image (in inkscape) was manually set to the shown color. I’m not sure what you mean about “mapping” no dialog pops up when I “import” the svg into lighburn.

here they are seperated in inkscape

and imported into lightburn

[berainlb (PY)]

@combatwombat42

not sure what you mean about “mapping”

I meant did you correlate the expected RGB colors from LightBurn when designing the file in Inkscape. I’m not familiar with the Color palette used but let’s assume for the moment that it’s correct.

Can you confirm whether or not you’re using disjointed lines for this? I’m asking because for example if you see where North America transitions to South America there is a shift in color on the LightBurn side. That tells me it’s treating those two differently. This wouldn’t be possible if that was a single continuous shape. I’m also wondering if you potentially have duplicate overlapping lines.

Are you able to share the SVG file for review?

[combatwombat42 (sam)]

sorry, i just edited the above post to show the different segments,

attached is the svg, it’s also avalible on thingiverse

[LightBurn (Oz)]

This file is weirdly built.

There are styles applied to all the shapes, specifying fill, stroke, or sometimes both values. LightBurn will only use fill OR stroke, with stroke color being chosen if both are present.

Your style for the gray parts specifies a light-gray fill, but a nearly black stroke outline, and that’s why some of the contents are ending up black.

The circles are using a style with a stroke color of #ED1D31 (mostly red, slightly purple), and then each circle itself also says it has an explicit stroke color of #00E000 (green).

I’ll have to look up the SVG rules and see which things are supposed to be kept here when given multiple colors.

[combatwombat42 (sam)]

This file is weirdly built.

Heh, yeah, that’s my trying to separate someone else work in a logical way.

I know you’re not inkscape support, but just so you know what I’m doing. I’m separating each triangle and it’s contents into a group (originally layer), and then shift selecting all the “circles” of each group and settting a stroke style

[LightBurn (Oz)]

The SVG spec says that an “inline” style applied to a shape will override any style applied through the class, and LightBurn was treating them the other way (class values would override local values).

I’ve changed it to work the other way, and this is the result when loading your file:

That appears to be correct to me, so this will go out with the next patch update.

[combatwombat42 (sam)]

In the meantime, I popped the file open in Code, removed the style

and it worked, Thanks!
as an embedded engineer, this is enough GUI crap for a year

[LightBurn (Oz)]

I feel your pain. Try Googling “style or class takes precedence for SVG”.

The SVG spec is a mistake - it’s ludicrously more complicated than it ever needed to be. It’s powerful, but it also makes it very hard to support it well.