SVG export dimensions seem slighly off about solvespace HOT 3 CLOSED

I think I found that certain SVG viewers would clip geometry entirely if the stroked line was outside the viewBox and/or width/height, hence the comment:

    (ptMax.x - ptMin.x) + 1, (ptMax.y - ptMin.y) + 1,
    (ptMax.x - ptMin.x) + 1, (ptMax.y - ptMin.y) + 1);
// A little bit of extra space for the stroke width.

It was a long time ago, though, and I don't remember details. Vector export could presumably be changed to determine the exact bounds allowing for stroke width, but that would be more work.

And I can't immediately reproduce your 50.799999, but it doesn't surprise me; floating point math is inexact. Is the difference causing a problem for you?

from solvespace.

The 50.799999 is just of cosmetic interest, in the SVG file it actually reappears as 51.800 (round again). I don't know how much of an issue the "plus one" thing is in general, for me it matters because I'm importing the SVG into GCAM for milling (therefore I do actually need accurate origins and sizes and so can only use the manual export option to hope to preserve them) and, well, the big problem is that the SVG canvas is upside-down, with (0,0) in the top left corner, so my imported workpiece obviously jumps up a unit, "sticking" to the invisible top of the larger-than-expected box. It clearly is possible to work around this by adjusting the offset value appropriately before exporting, but IMHO it's needlessly confusing and easy to forget (and one would probably not notice a 1mm displacement until it's too late).

So, considering that manual canvas sizing can already easily screw up the canvas / viewbox size in the SVG file anyway (resulting in coordinates outside the declared box) - would it be perhaps possible to disable the "unit-adding" mechanism at least in manual canvas mode...?

from solvespace.

Seems not unreasonable, just pushed the change. Let me know if you see any trouble.

from solvespace.