OpenBuilds CAM SVG import error.

New thread....straight to the point.

I had issues importing SVG files. The dimensions would be wrong. For example

Code:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
   width="612pt"
   height="792pt"
   viewBox="0 0 612 792"
   version="1.1"
   id="svg1"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs1" />
  <g
     id="surface1">
    <path
       style="fill:none;stroke-width:10;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;"
       d="M 0 0 L 720 0 L 720 720 L 0 720 Z M 0 0 "
       transform="matrix(0.1,0,0,-0.1,0,792)"
       id="path1" />
  </g>
</svg>

It detects the units from the height and width. Through discussion it defaults to 96dpi if it cant determine who created it. If you save out of inkscape with plain svg for example. If you save out as inkscape svg then openbuilds cam is happy, well okay I am happy as my 72 points becomes one inch. Instead of some other number.

Code:

   inkscape:version="1.3.2 (1:1.3.2+202311252150+091e20ef0f)"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"

Dont remember which but two of these three lines up front, at this time then take you down the path of success and the size of the path/box is 1 inch or 25.4 mm.

The bug I will call it is you instead get 25.4*0.9375 = 23.8125 mm instead.

If you change those to say mm instead of pt the tool recogizes the unts as mm now but still has this 0.9375 error it is converting millimeters to millimeters with a scaling of 0.9375.

Here is the issue. Not too far back sounds like inkscape changed from 90 to 96DPI and openbuilds cam did as well, but.....There appear to be a number of places that have the scaling.

90 / 25.4 = 3.543307087
96 / 25.4 = 3.779527559
and
90 / 96 = 0.9375

There is that percent error that affects these simple/plain svg files. (Inkscape or other generated).

You can grep for 3.543307 and find many hits. or grep for 'pt' or 'mm' and so on and run into a handful of places where code like this exists:

lw.svg-parser.js

Code:

                if (stringValue.indexOf('mm') !== -1) {
                    return floatValue * 3.5433070869;
                }
    
                if (stringValue.indexOf('cm') !== -1) {
                    return floatValue * 35.433070869;
                }
    
                if (stringValue.indexOf('in') !== -1) {
                    return floatValue * 90.0;
                }
    
                if (stringValue.indexOf('pt') !== -1) {
                    return floatValue * 1.25;
                }
    
                if (stringValue.indexOf('pc') !== -1) {
                    return floatValue * 15.0;
                }
    

If you go in and change the 1.25 to 1.3333333 for points.

Code:

                if (stringValue.indexOf('pt') !== -1) {
                    return floatValue * 1.25;
                }
    

Now when you import that file you get the correct 25.4 mm on a side as desired.

You can see the 90 in there for inches should be 96 and so on.

I did not find out when the other hits on this type of table are used, I just figured out the one that was affecting what I was trying to do.

 

Security Error: Content at file:///home/dwelch/Desktop/OpenBuilds-CAM/index.html may not load data from file:///home/dwelch/Desktop/OpenBuilds-CAM/workers/toolpath/worker/toolpathworker.js.

How does one resolve this (gcode generation when running a clone locally)?

 

lighttpd worked great (used it before so tried it first). thanks!

 

mm were broken as well would get that same 90/96 0.9375 ratio 100mm would import as 93.75mm The whole set is based on 90 (inches is 90 instead of 96 for the value, etc).

 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
width="100pt"
height="100pt"
viewBox="0 0 100 100"
version="1.1"
id="svg1"
xmlns="SVG namespace"
xmlns:svg="SVG namespace">
<defs
id="defs1" />
<g
id="surface1">
<path
style="fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;"
d="M 0 0 L 100 0 L 100 100 L 0 100 Z"
id="path1" />
</g>
</svg>



point

100/72 = 1.38888
1.38888 * 25.4 = 35.27777

if (stringValue.indexOf('pt') !== -1) {
return floatValue * 1.333333333
}

G1 F1000 X35.2778 Y35.2778 Z-1.0000 S1000
G1 F1000 X35.2778 Y0.0000 Z-1.0000 S1000

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
width="100mm"
height="100mm"
viewBox="0 0 100 100"
version="1.1"
id="svg1"
xmlns="SVG namespace"
xmlns:svg="SVG namespace">
<defs
id="defs1" />
<g
id="surface1">
<path
style="fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;"
d="M 0 0 L 100 0 L 100 100 L 0 100 Z"
id="path1" />
</g>
</svg>


if (stringValue.indexOf('mm') !== -1) {
return floatValue * 3.5433070869;
}

G1 F1000 X93.7500 Y93.7500 Z-1.0000 S1000
G1 F1000 X93.7500 Y0.0000 Z-1.0000 S1000

90/25.4 = 3.543307087
96/25.4 = 3.779527559

if (stringValue.indexOf('mm') !== -1) {
return floatValue * 3.779527559;
}


G1 F1000 X100.0000 Y100.0000 Z-1.0000 S1000
G1 F1000 X100.0000 Y0.0000 Z-1.0000 S1000



<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
width="1in"
height="1in"
viewBox="0 0 1 1"
version="1.1"
id="svg1"
xmlns="SVG namespace"
xmlns:svg="SVG namespace">
<defs
id="defs1" />
<g
id="surface1">
<path
style="fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;"
d="M 0 0 L 1 0 L 1 1 L 0 1 Z"
id="path1" />
</g>
</svg>


if (stringValue.indexOf('in') !== -1) {
return floatValue * 90.0;
}


G1 F1000 X23.8125 Y23.8125 Z-1.0000 S1000
G1 F1000 X23.8125 Y0.0000 Z-1.0000 S1000


if (stringValue.indexOf('in') !== -1) {
return floatValue * 96.0;
}


G1 F1000 X25.4000 Y25.4000 Z-1.0000 S1000
G1 F1000 X25.4000 Y0.0000 Z-1.0000 S1000


All of them not just 'pt'

 

does fix it for 'pt' it does not fix it for mm, in, cm, etc as the 1.25 is specific to pt. the code separates all of them pt, mm, in, cm... Did I misrepresent that pt did not work?

 

I get that and that is a fair argument, No I have not remotely read the whole svg spec, only wee tiny fractions through searches, but even where talks about the 1.25 and such is in reference to CSS not svg. One forum/question hit somewhere the person stated the 96dpi default for svg. Cant find that (yet).

So one could argue as a target you get to chose, my argument to that is you made changes to keep in sync with inkscape, so this is just a continuation of that. Clearly open builds cam detects the units from
width="612pt"
height="792pt"
If a plain file (And perhaps even if it has all the inkscape fields not, didnt test that yet). and you change those and it changes the scaling based on the if then else tree in that code.

So my argument is there were changes to be on par with inkscape so continue to make changes to be on par with inkscape and change the other places. I assume further that the if inkscape if illustrator if... is to keep on par with all of those. I guess a counter argument is that since it is not tagged as being from one of these specific tools (or stripped for various reasons before publication) then does it have to be inkscape like, response to that is most of your if-then-elses result in 96 with a default of 96. Hmm, I guess you could have 90 as the default if it falls through then the other tables dont have to change? I can test that...

I am struggling to understand any defaults related to svg specifically. Cant tell if there are or not. At this point despite the CSS comments in the svg spec, I dont even know if browser to browser, operating system to operating system it matters. As DPI with respect to pixels on wikipedia indicates that windows is one way and mac is/was another. (72/96). Not to mention the mixing of terms bouncing around pixels and points and dots. PostScript which is my origin is 72, but once that gets converted straight over to svg then it is in the svg domain, and no longer postscript.

Anyway, I can at least fix and run my own copy now if there is a desire not to change this. I will try changing the fall through default to 90 which should make the other scaling factors then work in these other or older files.

 

Okay and this makes sense...

just doing this

} else if (editor == "illustrator") {
resol = 72
} else if (editor == "Opentype.js") {
resol = 57
} else {
resol = 90;
}

Instead of resol = 96;

File: hello.svg was created in unknown version NaN. Setting import resolution to 90dpi


The 1.25 is now correct and

G1 F300 X25.4000 Y25.4000 Z-2.0000 S1000
G1 F300 X0.0000 Y25.4000 Z-2.0000 S1000

And get the 25.4 mm I expected.

(no need to test the other units as we can see the math on all of those is based on 90).

That feels cleaner.