Random garbage / Incorrect render on SVG files

[funinthefalls]

The center area of the web page is supposed to display the tool path. Mine seems to be all screwed up I have attached a screen shot for you. I am using: Latest version of Laserweb Marlin driver ( controller is Ramps 4.1/Arduino Mega 2560 with Full graphic RepRap LCD module) Quad core i7 PC

The laser works great using Inkscape/Turnkey plugin. When using LaserWeb I get the above issue.

[ghost]

Can you attach the file you opened?

I'll need it to debug (:

Peter

[ghost]

I can see the svg parser printed an error in the console log on the right.

[funinthefalls]

Here is the file. K40 front panel 12864 LCD inverted all vector.zip

[funinthefalls]

Sorry about that, hit the wrong button

[ghost]

Ahh ok no problem, all sorted then?

[funinthefalls]

+No not fixed, I had accidently hit the closed button

[cojarbi]

Im having the same issue. The error in the log seems to be the same. Something about not able to divide by 6

[ghost]

Yip, I can reproduce it too.

I just updated to latest svg.js, https://github.com/andrewhodel/millcrum/blob/master/inc/svg.js in my local branch, slightly better, but still some issues.

Note we need figure out what the pattern is, before we can escalate to millcrum's developers (they obviously wont support "this file doesn't work" type requests

I have to admit I put a lot more testing into DXF than into SVG. Personally I despise SVG (i'm an engineer, and never in any engineering drawing has a Pixel and a DPI (which varies between inkscape and illustrator too (92dpi vs 96dpi) been a valid unit of measurement. And even when SVG works perfectly you are forever dealing with scaling issues.

Quick history lesson:

See my rant on https://github.com/tbfleming/jscut/issues/44 in Jun 2015 already, which gave rise to Andrew writing me a DXF parser for Millcrum (which I then used to build the core of the import into Laserweb). Later Andrew added SVG to millcrum too, but as you see I hate SVG, I havent given it much testing to be honest.

My primary workflow is Sketchup -> Export to DXF as Polyline with the Guitarlist STL/DXF Plugin - that works flawlessly.

Continuing investigation of SVG though, but expect resolution to take a day or three...

I have also found other issues:

• Scaling on SVG wrong (already tested, not a laserweb issue, can reproduce on millcrum.com - issue logged https://github.com/andrewhodel/millcrum/issues/15
• Characters such as C and S parses in a wrong position

PS if you want a sanity check whether its laserweb or the svg library, test on millcrum.com too.

Above the svg library I have code that converts to gcode, renders the Gcode (i dont render the SVG - pointless, we want the render to show what the machine will do...) etc, so if it works on muiillcrum, but not on laserweb - it could be in those portions of the code...

[andrewhodel]

FWIW svg at least in Inkscape is not doing anything with pixels or dpi.

You can determine the units with these 2 entries:

width="600mm" height="400mm"

And then the points are in mm. You can send that directly to machine coordinates.

So I don't understand the dpi issues you are having, I think it's usually a misunderstanding in how a particular program is interpreting things.

[ghost]

Agreed @andrewhodel, yours does interpret it correctly as mm (according to the console log) but still comes out larger than drawn.

The biggest nightmares come from saving a inkscape file, someone works in illustrator on it, then send it back, for example. Real world examples.

[andrewhodel]

It doesn't seem so hard to me, the issue is that SVG as a standard has nothing to do with Illustrator and Inkscape. Their metadata and "easy usage" just make things harder than they really are.

On 12/26/15, Peter van der Walt notifications@github.com wrote:

Reopened #27.

---

Reply to this email directly or view it on GitHub: https://github.com/openhardwarecoza/LaserWeb/issues/27#event-500734811

[ghost]

Just an update:

See the comments on https://github.com/andrewhodel/millcrum/issues/15

• I will add the DPI/Scaling/etc to my own code, thats easy enough.

Though I am considering moving to another SVG library:

I just can't say LaserWeb supports SVG, if the upstream library does this:

and

When the two objects in question is a simple circle and a simple text. I could argue that your advanced file that came from somewhere on the interwebs and converted 100x times through 10 different toolchains, would cause garbage. But I can't point the blame at the user when my own tests of even simple objects in inkscape is mangled inside millcrum's svg.js.

Even worse, I cannot pin my project's success on an upstream developer with an attitude of "think I'll stick with that" and "I haven't used Laserweb. Same lack of a need for dxf or svg for me as well, I just wrote them because I was bored at the time." - and now tends to brush my bug reports for simple objects under the table, just because he doesnt have a need for them. Very sad

I thought we had a good working relation, but unfortunately it looks like its going a dead end :(

[ghost]

To avoid crossreading:

Here's my analysis of the Scaling issue:

Ok, I did a more in depth analysis of the issue:

1. Opened inscape and drew a 100x100mm square:

1. convert to path and save, view SVG as text:

   -- What I notice is that its a m type path object with 354.33... in there ( caught my eye because I saw it earlier)

2. Run it though svg.js

r.readAsText(osvg.files[0]); svg = new Svg(); svg.process(r.result); console.log('\n\nall paths',svg.paths); console.log('svg units '+svg.units);

1. console log gives me:

Aha, I recall seeing that 354 somewhere... Oh right, in the text view of the svg...

Since SVG saves as pixels, we should be doing (and now i recall this conversation from the early days of Lasaurapp)

DPI (90dpi for inkscape, 72dpi for illustrator) Unit (mm/inch/px) Path values should always be pixel, so pixel / dpi = inch lets test

354.(ignoring the decimals) / 90 = 3.9333` inch (90 dots per inch) 3.9333 * 2.54 = 9.99066666mm (I ignored the decimals remember, but yip that should have been my 100mm square.

So, bug in svg.js in that is assumes the values in the path is in the unit detected in the header Thats not the case, SVG is always in pixels (which is my frustration you've read me vent hundreds of times on SVG related topics, that a pixel isnt a standard unit of measure... grrr. So you always need that DPI in the calculation. And therefore the DPI NB NB has to be a attribute passed to svg.js as well (since it could be 90 (inkscape), could be 72(illustrator), could be custom (each of these allow for custom values to prepare files for print)

[ghost]

For the circles / bezier curves issues:

https://github.com/andrewhodel/millcrum/blob/master/inc/svg.js#L133

The objects that cause me trouble has been path, of type M (Move To commands) followed by C and c (http://www.w3.org/TR/SVG/paths.html#PathDataCurveCommands)

as well a M folloed by A (http://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommandshttp://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands) Millcrum's svg.js checks for lowercase c (https://github.com/andrewhodel/millcrum/blob/master/inc/svg.js#L220) but I dont see anything to handle A or C.

[ghost]

Sorry about all the posts today, but just jotting down all my thoughts and notes:

1. Autodetecting scaling:

Lasaurapp does it by checking the header:

https://github.com/stefanix/LasaurApp/blob/master/backend/filereaders/svg_reader.py#L220

[ghost]

And Lasaurapp parses M= C, Z, L, H, V, C, S, Q, T, and A https://github.com/stefanix/LasaurApp/blob/master/backend/filereaders/svg_path_reader.py#L81

Millcrum only does: M = L and C (and C seems to be buggy)

But apparently Inkscape doesnt follow the standards (; cough

[Cinezaster]

Wish I could help, I had the same issues, worked my way through it. First I converted everything to absolute paths Then converted: V & H to L and S & Q to C's. https://github.com/Cinezaster/svgPathToRoboCode/blob/master/parser/gcode_parser.js I did not tackle the inkscape DPI problem. But that would be somewhere to find in the header. I wanted to use http://fabricjs.com for handeling the svg's before converting it.

[ghost]

Excellent, something to build off. I have a slow week at the office. Let me play a bit (

[andrewhodel]

Well if you do it in python you'll have to have a server running the code, which means no using Chrome's serial API.

If I were using SVG and it was an issue affecting me I'd improve it, but there certainly should be enough there for someone else to add those few functions.

Again, if you write the SVG by hand then C will work with the code in SVG.js.

I apologize that Inkscape didn't follow the standard. In writing my 3d editor I do not think I will use the SVG or DXF standards and go straight from millcrum code to stepper pulses by redoing GRBL.

I don't like that SVG uses ABS and REL positions, it's intentionally difficult. The same is true of things in the DXF format.

[andrewhodel]

The ethos of open source is DIY, I don't understand why you wouldn't be happy that I shared what I did. I never joined this project it was something you started and added me to.

I apologize that you were under the impression that I was going to dedicate time to this, from my viewpoint you were simply taking what I had taken the time to build and using it for what you could. I did not understand that I was committed to developing anything. That's just not how open source works.

Look at the history of GRBL, the Dutch guy builds it and quits at .6 or something, 2 other devs pushed it on to what it is today and Marlin was forked off the original. All without the continued effort of the original dev.

He took the ideas from age old ones, but he helped by contributing what he had the desire to. It's about the code not the projects with open source.

The same is true of GNU, The Linux Kernel and countless other open source projects which we all use and depend on. The whole bit of it is that we depend on the code to continue working, not the people. The people can continue on with what they please, that's the beauty of it.

[ghost]

@martinxyz i also found https://github.com/tmpvar/svgmill?files=1 - looks like. Svgreader.js is already from the lasaur project ( in svgmill)

[ghost]

https://github.com/openhardwarecoza/LaserWeb/commit/f6cb1783fad19d80401b53d46e0ab300aa180496 brings back SVG, now based on an old Lasersaur importer. Not ideal, but accurate! I think we can add layer support and fills to this quite easily (:

Also, no garbage. At least with none of the test files I have.

[funinthefalls]

Looking good, scaling seems to be a bit off

[ghost]

Yip, very early. Literally just got it producing results when i went to bed. In the morningi'll kick off again (or, feel free to help! Always open for pull requests (: )

[ghost]

To do list:

• Scaling (want my bounding box from the Raster module in here too)
• Layers (power/speed per layer like Lasersaur has and like i have in dxf in laserweb)
• svg fills (engraving)
• double paths - looks like on some more complex images it takes the outlines of two adjascent areas next to each other. Will post a pic tomorrow of what i mean - has to be fixed
• overall LaserWeb - more interactivity through the three.js canvas (render svg to the canvas, and overlay gcode view or something like that)

[ghost]

Well, @funinthefalls , that 'K40 front panel 12864 LCD inverted all vector.zip' test file that sparked this thread, now renders like this:

I think we can close this one (: The new SVG library is live and much better (except some improvements over the next few days like colors, etc etc) but as is we are better off than we were under the old one, so I am considering the bug squashed and closing the Issue