Tried some searches not finding if this has been asked before or not. Take a very simple svg file. Code: <?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="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"> <defs id="defs1" /> <g id="layer1" transform="translate(0,-100)"> <rect style="fill:none;stroke:#000000;stroke-width:0.1" id="rect1" width="100" height="100" x="0" y="100" /> </g> </svg> A 100x100mm rectangle. Open it with openbuilds cam and it shows it much less than 100mm. And with cnc vector no offset you get this Code: G1 F1000 X93.7500 Y93.7500 Z-1.0000 S1000 G1 F1000 X93.7500 Y0.0000 Z-1.0000 S1000 So openbuilds cam thinks 100mm is really 93.75. Use inkscape to convert to DXF and you get 100x100, but it is not one path so you have to select it weird. Moveto/lineto same deal 100mm becomes 93.75. I think it is a percentage error thing as if I make a different size object then the error is not 6.25mm it is some other amount. Code: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg width="612mm" height="792mm" 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:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 0 0 L 1000 0 L 1000 1000 L 0 1000 Z M 0 0 " transform="matrix(0.1,0,0,-0.1,0,792)" id="path1" /> </g> </svg> Inkscape generated or poppler/cairo and there does not appear to be anything wrong with these svg files. Disturbing amount of error. Does openbuilds cam support svg?
Looks like incorrect DPI - what version of Inkscape are you running? OpenBuilds-CAM/js/svgparser.js at d39bc9a66c044668e3df4b1ddd79c7640184fc95 · OpenBuilds/OpenBuilds-CAM Or try to export at the expected DPI Also convert your entities to Paths. Thats a Rect not a Path, fine for simple shapes, but better to get into the habit of making everything Paths. Read docs:software:file-errors [OpenBuilds Documentation]
dots per inch is 72. Can easily demonstrate the same problem with points instead of mm. And as demonstrated it fails with an svg generated from other well known svg tools than inkscape. Other cam programs do not have a this issue. You get G0 X0 Y0, G1 X100 Y0 and so on as desired. Inkscape itself can read the file properly. (well of course inkscape sees it as an image so adds the line width as part of the image size then when you scale you get yet another error, but this can be easily managed).
Please show changes to either of the svg files (box or path based) that would import as 100x100mm instead of 93.75
It actually does. Wouldn't ask if it doesn't. If you clicked the code reference provided, you might notice the parser heavily relies on that information to make a decision on the DPI to assume the file is exported as Did you click? If so you'll notice the code uses the Inkscape Tag and version to determine the default DPI (As inscape changed between 90 and 96 dpi over the years) SVG is pretty much unitless. The internal unit is px. px * dpi = real world measurement - so scaling issues always relate to DPI SVG doesn't have a standardised way to communicate what the DPI is so we have to guess based on presence of flags like the editor or editor version. So if I open Inkscape and draw a 100x100 px square Just do a File > Save then it has the expected metadata in the header Code: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" width="210mm" height="297mm" viewBox="0 0 210 297" version="1.1" id="svg8" inkscape:version="1.0.1 (3bc2e813f5, 2020-09-07)" sodipodi:docname="100x100.svg"> <defs to obtain a Editor type (Inkscape) and version (never use it so installed version here is far behind, on 1.0.1) Anyway Loading that into CAM the code can do its thing to parse out the metadata, see what version it is, and then scale it accordingly Giving you a perfect 100x100mm Square in CAM
Your SVGs seem to have no metadata to satisfy the editor field, so its handled as Code: File: forum-thread-144159-file1.svg was created in 'unknown' version 'NaN' Setting import resolution to 96dpi There is an unassigned internal enhancement request for "enter the DPI you used" popup for the unidentifyable cases, maybe we can push that a little toward the top, but just exporting with the Metadata (or without metadata but as 96 DPI) will get you sorted for now (As you mention using Inkscape v1x, the default would have been 96dpi even if the metadata is removed)
Okay I see that why would it default to a 96 pixels per inch default when it sees points as the units rather than a default dots (points) per inch of 72? The file says points not pixels. And now if you go into the file and say mm not dots not pixels, etc. so there are no dots per inch it is just mm. then it still has an issue, does it convert from mm to dots at 72 per inch then turn around and convert dots/points to pixels at 96? While you were doing that here is what I was working on: And a similar bottom line of. diff test1.svg test5.svg 7a8,9 > inkscape:version="1.3.2 (091e20e, 2023-11-25)" > xmlns:inkscape="Inkscape Namespace | Inkscape ---------------------------------------------------------- Full story. Create a path: %! 0 0 moveto 72 0 lineto 72 72 lineto 0 72 lineto closepath stroke showpage ps2pdf test.ps pdf2svg test.pdf test.svg # other platforms pdftocairo -svg test.pdf test.svg Giving this, unmodified: <?xml version="1.0" encoding="UTF-8"?> <svg xmlns="SVG namespace" xmlns:xlink="XLink namespace" width="612pt" height="792pt" viewBox="0 0 612 792" version="1.1"> <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)"/> </g> </svg> width="612pt" height="792pt" 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)"/> units are in points (72 points/dots per inch of course) In SVG format it is a path. Moveto 0 0 Lineto 720 0 Lineto 720 720 Lineto 0 720 Z closepath ( 0.1 x scale ,0,0, -0.1 y scale (postscript origin lower left, svg upper left) ,0,792)"/> giving Moveto 0 0 Lineto 72 0 Lineto 72 72 Lineto 0 72 Z closepath A one inch spare path. Estlcam, engraving: (No. 1: Engraving 1) G00 X0.0000 Y25.4000 G00 Z0.5000 G01 Z0.0000 F600 S24000 G01 Z-1.0000 G01 Y0.0000 F1200 G01 X25.4000 G01 Y25.4000 G01 X0.0000 G00 Z5.0000 G00 Y0.0000 25.4 mm = 1 inch = 72 dots. Correct, no error. jscut.org ; cut G1 X0.0000 Y25.4000 F1016 G1 X0.0000 Y0.0000 G1 X25.4000 Y0.0000 G1 X25.4000 Y25.4000 25.4 correct, no error carbide create X25.400 Y25.400 X0.000 Y0.000 25.4, correct, no error OpenBuilds CAM immediately after opening file the rulers on the side show it is less than 25.4 mm, so already a problem. CNC: Vector (no offset) G1 F1000 X23.8125 Y23.8125 Z-1.0000 S1000 G1 F1000 X0.0000 Y23.8125 Z-1.0000 S1000 G1 F1000 X0.0000 Y0.0000 Z-1.0000 S1000 G1 F1000 X0.0000 Y0.0000 Z-1.0000 S1000 23.8125, error, 93.75% of the correct dimension. (just like the 100mm error). Without inkscape so far, just poppler and cairo (inkscape apparently uses poppler). Using inkscape to simply open and save as plain.svg <?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="SVG namespace" xmlns:svg="SVG namespace"> <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 just breaks the items into separate lines (Easier to read, this is what I used in the original question). Dimension is wrong on read. G1 F1000 X23.8125 Y23.8125 Z-1.0000 S1000 G1 F1000 X0.0000 Y23.8125 Z-1.0000 S1000 and bad on output. If you use inkscape to simply open and save as inkscape svg... It works. G1 F1000 X25.4000 Y25.4000 Z-1.0000 S1000 G1 F1000 X0.0000 Y25.4000 Z-1.0000 S1000 Experimentally finding the minimal delta. diff test1.svg test5.svg 7a8,9 > inkscape:version="1.3.2 (091e20e, 2023-11-25)" > xmlns:inkscape="Inkscape Namespace | Inkscape Which is <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg width="612pt" height="792pt" viewBox="0 0 612 792" version="1.1" id="svg1" inkscape:version="1.3.2 (091e20e, 2023-11-25)" xmlns:inkscape="Inkscape Namespace | Inkscape" xmlns="SVG namespace" xmlns:svg="SVG namespace"> <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> So I guess the bottom line is that OpenBuilds CAM needs inkscape format svg files not just svg files? -------------------------------------------- And the answer appears to be yes, you cannot just import svg files they have to be inkscape marked? Web page says: OpenBuilds CAM will allow you to Import DXF/SVG/PNG/BMP/JPG/Gerber/Excellon files Maybe that should clarify SVG(inkscape) or something like that. That error now smells familiar as with estlcam you have to specify the units (which with inkscape and svg or dxf is a gamble with estlcam unless you know how to examine the file formats). If I select pixels you get the 96 per inch conversion if you select points then you get the natural 72 per inch. ----------------- further reading. Looks like the mac world used 72 ppi as the default and the windows world 96 for various reasons. Postscript (I seem to remember adobe and postscript being associated with macs well before windows) PostScript uses the point as its unit of length. However, unlike some of the other versions of the point, PostScript uses exactly 72 points to the inch. ---------------------- Svg spec does mention "1pt" equals "1.25px" (and therefore 1.25 user units) pt: points -- the points used by CSS2 are equal to 1/72th of an inch. OpenBuilds does react to the units from width="612pt" height="792pt" and scale the path according to that unit, change it to mm and there are no dpi now, the original svg I started with. we can have that discussion, as to why open builds has a dpi association with millimeters. or I can try this: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg width="612mm" height="792mm" viewBox="0 0 612 792" version="1.1" id="svg1" xmlns="SVG namespace" xmlns:svg="SVG namespace"> <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> G1 F1000 X67.5000 Y-0.0000 Z-1.0000 S1000 G1 F1000 X67.5000 Y67.5000 Z-1.0000 S1000 G1 F1000 X0.0000 Y67.5000 Z-1.0000 S1000 and <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg width="612mm" height="792mm" viewBox="0 0 612 792" version="1.1" id="svg1" inkscape:version="1.3.2 (091e20e, 2023-11-25)" xmlns:inkscape="Inkscape Namespace | Inkscape" xmlns="SVG namespace" xmlns:svg="SVG namespace"> <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> gives G1 F1000 X72.0000 Y72.0000 Z-1.0000 S1000 G1 F1000 X0.0000 Y72.0000 Z-1.0000 S1000 G1 F1000 X0.0000 Y-0.0000 Z-1.0000 S1000 I dont see where dpi is associated with mm as a unit. clearly it sees mm vs points. Sounds to me like either openbuilds is right that 96dpi is the default and inkscape, estlcam, and carbide create at a minimum are wrong or ... Interesting exercise and I should have seen that 72/96 = 75% okay that is not the 93.75 percent that I am seeing so you had me convinced, but now...76.8 is the the assumed default dpi? Bottom line other tools (I have tried so far) you do not have to use inkscape svg format, but openbuilds you do, if you want to use svg and not have to fix the scaling. Of course inkscape messes up the scaling take the file. <?xml version="1.0" encoding="UTF-8"?> <svg xmlns="SVG namespace" xmlns:xlink="XLink namespace" width="612pt" height="792pt" viewBox="0 0 612 792" version="1.1"> <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)"/> </g> </svg> I pretend I dont see that when I switch to inches it is not 1 inch but I want to double it so select 2 inches. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg width="612pt" height="792pt" viewBox="0 0 612 792" version="1.1" id="svg1" sodipodi:docname="test6.svg" inkscape:version="1.3.2 (091e20e, 2023-11-25)" xmlns:inkscape="Inkscape Namespace | Inkscape" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns="SVG namespace" xmlns:svg="SVG namespace"> <defs id="defs1" /> <sodipodi:namedview id="namedview1" pagecolor="#505050" bordercolor="#eeeeee" borderopacity="1" inkscape:showpageshadow="0" inkscapeageopacity="0" inkscapeagecheckerboard="0" inkscape:deskcolor="#505050" inkscape:document-units="pt" inkscape:zoom="0.69507576" inkscape:cx="407.86921" inkscape:cy="528" inkscape:window-width="1680" inkscape:window-height="973" inkscape:window-x="0" inkscape:window-y="26" inkscape:window-maximized="1" inkscape:current-layer="svg1" /> <g id="surface1" transform="matrix(1.9726027,0,0,1.9726027,0.48630137,-699.78767)"> <path style="fill:none;stroke:#000000;stroke-width:10;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-opacity:1" d="M 0,0 H 720 V 720 H 0 Z m 0,0" transform="matrix(0.1,0,0,-0.1,0,792)" id="path1" /> </g> </svg> This is not correct transform="matrix(1.9726027,0,0,1.9726027,0.48630137,-699.78767)"> G1 F1000 X50.2757 Y25.2285 Z-2.0000 S1000 instead of 50.8 but that is an inkscape thing (and not openbuilds) which is not a bug because inkscape deals with it as a image, including the width of the line/path. every tool that supports svg files will suffer the error that comes from users using inkscape. (change the stroke-width to solve that). ....... } else if (editor == "illustrator") { resol = 72 <?xml version="1.0" encoding="UTF-8"?> <!-- Generator: Adobe Illustrator 19.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> <svg xmlns="SVG namespace" xmlns:xlink="XLink namespace" width="612pt" height="792pt" viewBox="0 0 612 792" version="1.1"> <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)"/> </g> </svg> G1 F1000 X31.7500 Y31.7500 Z-1.0000 S1000 so what happened there??? 31.75? shouldnt that be 72? -------------------------------- Anyway while doing a demo, I hit this confusing openbuilds cam thing, and now I know how to work around it. You probably didnt read this far with all the chaos above. If you did I am even more confused than when I started this thread. But I can get the desired result now. I cant imagine I am the first one so is this already documented somewhere or some other FAQ that already covered this topic (have to use inkscape format svg).
Not specifically, but if in doubt just use 96dpi (Pending the future update where we can maybe ask you what DPI its at.) for the export from anything else (so it strikes that last "else" condition). It reads SVG from anywhere. No worries about that. But moving between applications, knowing we expect 96pdi (standard) would help ensure whatever you export it from, exports as 96dpi. Inkscape used to be the outlier (90dpi) for a while but least they also caught up and switched to 96dpi in v1.x, so its rare to still find input files that aren't 96dpi. Review OpenBuilds-CAM/js/svgparser.js at d39bc9a66c044668e3df4b1ddd79c7640184fc95 · OpenBuilds/OpenBuilds-CAM alongside OpenBuilds-CAM/lib/lw.svg-parser at d39bc9a66c044668e3df4b1ddd79c7640184fc95 · OpenBuilds/OpenBuilds-CAM to see what it does, and no its not perfect, but as its an open source project - if you want to help improve it you are always welcome The bane of graphics apps everywhere. SVGs units are a minefield. CAD guys got it sorted, DXF carries the Units - much easier. Some history Units In Inkscape - Inkscape Wiki And yeah some other CAMs have it more tuned in, but you are about the first person having issue with this in a long time - most others have more standard workflows of saving SVGs from modern graphics design suites that usually uses the 96dpi standard. Unless they manually change DPI on export, it is just usually 96dpi and works. 96dpi x 93.75% = 90dpi So exported as 90 dpi?, should just export the SVG as 96dpi. We'd only try 90dpi if the metadata says its inkscape 0.92 or newer, but older than 1.0 - newer (and more widely used on other applications, international CSS standard, etc) were all 96dpi. As it doesn't have metadata that matches, you end up where we guess it should be 96dpi, but its exported at 90dpi, thus the size difference.
surprised I am the first and inkscape is using 72 for some reason I still dont understand why when the svg is in units of mm (which is in the section under Units in the svg spec) that openbuilds cam does some conversion to millimeters from millimeters which just happens to have this 93.75% thing in there (why is it converting from mm to mm and why does it not have a one to one conversion when it does?)(the mm unit is a tangent to the points discussion and yet another thread if we cant sort this out here) Note I am hoping we can completely delete this thread once understood/resolved. (I created this chaos, very happy to have this discussion with you as I am quite interested in this tool) and also you are telling me 96PPI/DPI 72 points / 96 ppi = 0.75 inches 0.75 * 25.4 = 19.05 millimeters Yet openbuilds generates the 93.75 % not 75 percent G1 F1000 X23.8125 Y23.8125 Z-1.0000 S1000 G1 F1000 X0.0000 Y23.8125 Z-1.0000 S1000 23.8125 / 25.4 = 0.9375 inches 72 points / 0.9375 inches = 76.8 ppi/dpi so this is not a 96dpi/ppi fall through the if then else tree. forking the repo and trying to figure out how to run it on my own (and change that fall through default is on the long list of things to (maybe) try (today)). On the inkscape front open that file and you get 73points not 72 as described stroke-width:10 times 0.1. and then switch the units to inches it is 1.014 73/72 = 1.013888 inches 73/96 = 0.7604 inches it is clearly not using 96 as a default. omg so I guess I have to hop on the inkscape forum as well to find out why 72 is != 96. I noticed that openbuilds cam changed on me yesterday some controls moved while I was in the middle of all of this (generate gcode was per toolpath, now it is with export gcod). I could swear that a few days ago when trying this I got a pop up that said this is not an inkscape format file something something. But it is certainly not doing that for me now if I am even remembering which cam tool did that (all the others are happy to consume what inkscape calls a plain svg). Did it have a popup a few days ago that is now suppressed? I found the illustrator example (unless forced I have no desire to go install that simply to find out what its meta data strings look like), on a how to page about making svgs and that page was showing it to say remove remove that metadata line before publishing your svg. And as shown that metadata line did not produce 72 dpi nor 96 openbuilds cam did some other thing with it I dont yet understand. (did I grab the wrong file and have one of the 100 x 100 units one, hmmm). <?xml version="1.0" encoding="UTF-8"?> <!-- Generator: Adobe Illustrator 19.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> <svg xmlns="SVG namespace" xmlns:xlink="XLink namespace" width="612pt" height="792pt" viewBox="0 0 612 792" version="1.1"> <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)"/> </g> </svg> G1 F1000 X31.7500 Y31.7500 Z-1.0000 S1000 31.75 / 25.4 = 1.25 72 / 1.25 = 57.6 sigh Yes SVG is a minefield, but folks dont know that. You posted an output that I assume was from openbuilds. I dont see a console on the page anywhere, or a way to get to one. How would one see that kind of thing and or is this a todo to have something like that (imo a popup or warning of some kind would greatly help this problem as without guidance folks do not know they need to save as inkscape svg vs plain svg, for example). one more thing. since you said file->save without other direction. go create a box in inkscape, set the units to mm, make it 100mm on a side, resize to content (yet another thing with openbuilds, hopefully a future todo thing), then save as or file->save plain svg. it comes in as 93.75 or really probably smaller since inkscape doesnt make it 100mm it makes it 100mm minus stroke width transform="translate(-38.038455,-109.60471)"> <path id="rect1" style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.113841" d="m 38.095375,109.66163 h 99.886165 v 99.88616 H 38.095375 Z" /> sure, sounds like you can scale/fix it in openbuilds. but how does that help the user? same user perhaps intentionally or accidentally some day ends up with the save using inkscape svg and now the 100mm by 100mm is not smaller it looks to be 100 on the ruler on the tool. this doesnt confuse anyone? I like what I am seeing it was just an instant fail from the start and consumed a lot of hours trying to understand. It still makes no sense to me, but yes there is a workaround....but that makes no sense either, LOL, but it works. Would be nice if things just made sense. I would still like to understand why 100mm = 93.75 mm in a direct mm to mm conversion. And why it is using 76.8dpi not 96 dpi (and why inkscape is using 72dpi and not 96)... If not already there I recommend a FAQ that indicates inkscape svg not plain svg when folks are prepping files for this tool. And/or use the scaling within the tool as your final scale instead of inkscape (well that creates the origin problem yes? which I hope is a todo). And maybe that is already in a tutorial, which I didnt go through yet as I was trying to come up with searches related to svg and gcode output and this big error on import, etc. I am very much liking the instant support, greatly adds to the desire to use the tool. If Im the only one on the planet to ever hit this fine, maybe there is another channel where we can further communicate on this or other topics. If you want to delete this thread or if I am able, that is fine. as written it is not useful to folks. if there is something useful a new one can be created.
I will look into it during the work week, but that basic parser has been in use for so long I don't even remember all the interactions. No worries, can keep it on the forum If you can find something other than the metadata we already use, that can be consistently parsed to determine what scaling to use (output out of svgparser * scale = mm) we can add it to the if/else too Check dev console (ctrl+shift+i > console tab) for debug log, will show which it used, can click through and see where it branched off. This example I will have to check but the math suggest somewhere is still a 90 vs 96dpi interaction as 96*93.75%=90 I will have to schedule time for a full debug to answer all your other questions too. Or maybe just put that time into exploring other parsers might be something newer out since we wrote that for laserweb back in 2016 Any webserver - just plain html/css/js. I usually just pop it into a http-server for local tests Doesn't sound familiar, most of current rework is Prettying it up and adding support for the LEAD Plasma add on you can review commit log on Commits · OpenBuilds/OpenBuilds-CAM
yeah looked at commits. it must have been another tool that had that popup. So this is interesting...cloned the repo. (can open a javascript terminal to see the output, duh, first time for me messing with javascript). console.log(editor, version) resol = 72; console.log("File: " + name + " was created in " + editor + " version " + version + ". Setting import resolution to " + resol + "dpi") scale = 25.4 / resol sure scale = 1 / resol / 25.4 is the same, maybe a weee weee bit of rounding error. that didnt change anything but left that line in there... 31.75 mm from 72x72 point square path. console.log(editor, version) resol = 96; console.log("File: " + name + " was created in " + editor + " version " + version + ". Setting import resolution to " + resol + "dpi") scale = 25.4 / resol 23.8125 mm so this 23.8125 is from a 96 dpi/ppi. as you indicated. but makes no sense 72 points / (96 points / inch) = 0.75 inches * (points/points) = 0.75 inches * 25.4 mm/inch = 19.05 mm not 23.8125 72 / 72 = 1.0 inches. = 25.4 mm not 31.75 scale = 25.4 / 72 = 0.352777778 0.352777778 * x = 31.75 x = 90 scale = 25.4 / 96 = 0.264583333 0.264583333 * x = 23.8125 x = 90 There is a common factor in there. and the units are scale = (mm/inch) / (points/inch) = (mm/inch) * (inch/point) = mm/point mm / (mm/point) = points x = 90 points, I am missing some unit. So it is not strictly the resol = 96 vs 72 there is some other factor somewhere affecting this.
Okay so I got it!! 25.4 / 90 = 0.282222222 90 / 25.4 = 3.543307087 lib/lw.svg-parser/src/tagparser.js: return floatValue * 3.5433070869 if(i.indexOf("mm")!==-1)return 3.5433070869 lib/lw.svg-parser/dist/lw.svg-parser.min.js 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 } you did a 90dpi to 96 dpi change a while back. 96/25.4 = 3.779527559 Ohh, look at this return floatValue * 1.25 90/1.25 = 72 but 96/1.25 = 76.8 we saw that factor above... so we want this to be umm 96/72 = 1.33333 if (stringValue.indexOf('mm') !== -1) { return floatValue * 3.779527559 } if (stringValue.indexOf('cm') !== -1) { return floatValue * 37.79527559 } if (stringValue.indexOf('in') !== -1) { return floatValue * 96.0 } if (stringValue.indexOf('pt') !== -1) { return floatValue * 1.333333333 } if (stringValue.indexOf('pc') !== -1) { return floatValue * 15.0 } nope if(i.indexOf("mm")!==-1)return 3.779527559*n; if(i.indexOf("cm")!==-1)return 35.433070869*n; if(i.indexOf("in")!==-1)return 96*n; if(i.indexOf("pt")!==-1)return 1.333333333*n; if(i.indexOf("pc")!==-1)return 15*n; nope if (stringValue.indexOf('pt') !== -1) {\n return floatValue * 1 lib/lw.svg-parser/dist/lw.svg-parser.js: if (stringValue.indexOf('pt') !== -1) { if (stringValue.indexOf('pt') !== -1) { return floatValue * 1.3333333333; } That got it!!! File: hello.svg. Setting import resolution to 96dpi svgparser.js:66:11 blur viewer-pause.js:17:13 copy: Object { uuid: "A27DF371-3815-48FE-BE08-C5BF3359C4A6", name: "surface1", type: "Line", parent: {…}, children: [], up: {…}, position: {…}, rotation: {…}, quaternion: {…}, scale: {…}, … } advanced-cam.js:67:17 0 advanced-cam.js:72:19 blur viewer-pause.js:17:13 Metro 4 - v4.2.42. Built at: 07/05/2019 22:20:03 metro.js:286:20 This operation contains 0 Open Vectors, and 1 Closed Vectors advanced-cam-modal.js:623:11 blur 2 viewer-pause.js:17:13 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. I wish I could generate gcode with my local copy. I modified the console long to get rid of the NaN just in case that was upsetting something... There are a lot more places in the code where it is still 90dpi and not 96 as a default. 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.3333333333; } if (stringValue.indexOf('pc') !== -1) { return floatValue * 15.0; } if I fix the mm one to if (stringValue.indexOf('mm') !== -1) { return floatValue * 3.779527559; } then Nice! it fixed that one as well You still need to explain to me how 72 points becomes 25.4 mm instead of 96 points. Well I have some ideas, butt end of the day, changing lib/lw.svg-parser/dist/lw.svg-parser.js makes me a very happy camper. Thanks for tolerating me... from the svg spec. All coordinates and lengths in SVG can be specified with or without a unit identifier. When a coordinate or length value is a number without a unit identifier (e.g., "25"), then the given coordinate or length is assumed to be in user units (i.e., a value in the current user coordinate system). One px unit is defined to be equal to one user unit. The other absolute unit identifiers from CSS (i.e., pt, pc, cm, mm, in) are all defined as an appropriate multiple of one px unit (which, according to the previous item, is defined to be equal to one user unit), based on what the SVG user agent determines is the size of a px unit (possibly passed from the parent processor or environment at initialization time). For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi). Then, for all processing of SVG content: "1pt" equals "1.25px" (and therefore 1.25 user units) "1pc" equals "15px" (and therefore 15 user units) "1mm" would be "3.543307px" (3.543307 user units) "1cm" equals "35.43307px" (and therefore 35.43307 user units) "1in" equals "90px" (and therefore 90 user units) so clearly 90 user units per inch but to change to 96 DPI need a px to DPI multiplier (and/or just embed it in the code with 1.3333 and so on as I did).
