SVG importing; aaargh

[easytarget (Owen)]

Ok, so I have a small .svg file that I’ve had the goal of getting to import nicely into LW. Currently it fails like this:

The actual SVG is:

HUMMM!

I’ve been picking at this on and off since May last year and finally:

This is not the only ‘bad’ svg I’ve encountered, and I’ve seen others report similar issues.

[easytarget (Owen)]

The TL;DR

When you load an image into LW it is initially parsed to a tree of individual svg tags, but after this the data is split. One for the image to be used in the display, and separately to obtain all the cutting paths within the image.

The tag processing was failing for the displayed image, while the path extractor would normally work even if the image looked like gash in the display.

• I would often load SVG’s that looked terrible while laying them out, but still worked if you generated cutting operations from them.

Earlier today I finally worked it out, Floating point precision is really messing things up, tiny errors were accumulating in the maths, the end result being that paths were not being ‘closed’ since the end point might be different by 0.00000001 units from the start point, etc. This made the ‘is this path starting/ending at the same point?’ tests fail to mark the path closed.

• This badly affects the display tag processor
• The cutting path generator has more tolerance built in against this

The ‘Success’ image above is the result of me doing some simple rounding on the paths before they are stored, eg x=number(x.toFixed(4)); and similar as the values are added to paths.

I need to refine this; for a start I want to round() the values, but this opens up issues(*) so I need to play further with it. Also I want to make this a setting exposed in the File Settings so that the user gets a ‘svg precision’ or similar setting.

A secondary issue being that paths without a stroke colour defined were being rendered black, but with an opacity of 0, hiding them in the display. However, they would still produce cutting paths; which could be very confusing.

(*) Floating point math on binary computers, Hateful. I think my next project should be some kind of ‘analog computer gcode generator’
read and weep:

How to round float numbers in javascript?

[easytarget (Owen)]

A followup to myself;
I’ve implemented options in Settings->File for :

• Svg Precision; defining how many decimal places we should round() to before processing svg paths into the workspace. This is done after the dpi and offset calculations have been done. It’s not perfect, but much better than it was before.
• Default Path Color; when a path has no default ‘stroke’ color in the document it will be rendered in this color; defaults to a dark’ish grey.
• Fill Opacity; allows you to lower the opacity of filled areas when documents are imported; this can help to highlight paths and shapes hidden under filled areas. Cutting operations will ignore the opacity when calculating power levels; but ‘raster merge’ will use it, which can be confusing so I default it to 100%

Finally; having sorted that out I finally added a feature I have wanted in the past; 'select by color’.
You can highlight one or more items in the document tree; then select all other items with matching stroke colors with a single click, or shift-click to match fill colors.

Super-dooper handy for sorting out some of the random SVG’s you get on download sites. The ones where the uploader has used colors instead of layers or groups to distinguish different cuts.