search

sameer / svg2gcode

Convert vector graphics to g-code for pen plotters, laser engravers, and other CNC machines
https://sameer.github.io/svg2gcode
MIT License
244 stars 48 forks source link

CLI --output syntax is counterintuitive #59

Closed MadTooler closed 1 week ago

MadTooler commented 1 month ago

Hey Sameer, hope all is well.

I am getting around to connecting all my custom workflow of svg to gcode to machine control, and I keep fighting with svg2gcode and its varying choices of origin output.

The initial issue is a varying origin pending if the path is larger than the viewbox bounds, which I run into a lot of with large paths that are not necessarily constrained to the viewbox/page size in inkscape. Depending on where it may go beyond the viewbox, or not, the choice of X and Y Zero vary. Some of the results are similar to what I noted in my previous issue "Origin based on svg 0,0 #36."

When I use the --origin parameter, as you added after issue "SVG offset #7," I found I cannot use negative values. Note the beyond viewbox seems to affect this as well. Also, I see the web interface offset is being scaled by the DPI (as in an offset of 10 turns into 2.64...).

Four output option modes I am thinking of, but have not fully thought through how others may fully appreciate :

  1. Default as is now... whatever relation to viewbox/page bottom left as is in SVG is maintained and zero,zero is from viewbox (corrected to output as expected even when path goes beyond viewbox bounds).
  2. Simple origin offsets as already exist except allow negative values too.
  3. New... origin/offset is calculated per some sort of reference marker in the SVG. The marker itself would be ignored in the output, maybe ignored in a similar way as you were thinking of in issue "How to ignore/skip SVG elements? #57."
  4. New... ignore viewbox/page size and output with origin as bottom left of the extents of the paths only. Possibly a further option on this one to choose other corners or middle/center locations instead.

I did try to test implementing some of these options myself, but I didn't have luck working through the rust environment.

What are your thoughts?

Thanks

sameer commented 1 month ago

Also, I see the web interface offset is being scaled by the DPI (as in an offset of 10 turns into 2.64...).

This sounds like a bug. After I fixed the way viewboxes and dimensions are handled, looks like there is an incorrect DPI scaling applied assuming it is in points. I'll push a fix for this soon.

Simple origin offsets as already exist except allow negative values too.

I don't see any reason not to allow this. Will look into why it's not working.

sameer commented 1 month ago

This sounds like a bug. After I fixed the way viewboxes and dimensions are handled, looks like there is an incorrect DPI scaling applied assuming it is in points. I'll push a fix for this soon.

Fixed by e50e42b2c60ce4793457c480c92bd66abaec86ca. The web UI should be up to date now.

MadTooler commented 1 month ago

Excellent! Both of those items seem to be working now on web UI. Thanks.

I assume yes... Did you update the CLI core as well?

I have not run the update on my RPI for a rust crate type setup. I will have to look into the syntax.

sameer commented 1 month ago

Excellent! Both of those items seem to be working now on web UI. Thanks.

No problem, glad we got that fixed.

I assume yes... Did you update the CLI core as well?

I have not run the update on my RPI for a rust crate type setup. I will have to look into the syntax.

Yes the CLI has also been updated.

MadTooler commented 1 month ago

CLI errors when outputting an --origin with -x value. With -y it acts happy. Where I output --origin -70,-30, it gave me:

error: Found argument '-7' which wasn't expected, or isn't valid in this context

sameer commented 1 month ago

CLI errors when outputting an --origin with -x value. With -y it acts happy. Where I output --origin -70,-30, it gave me:

error: Found argument '-7' which wasn't expected, or isn't valid in this context

I believe it's interpreting -7 as a flag and not an argument. Try putting it in quotes: '-7'.

MadTooler commented 1 month ago

I believe it's interpreting -7 as a flag and not an argument. Try putting it in quotes: '-7'.

That is what I was thinking. I tried ' and " for just the x and for both, no joy. Still does not like the -x. I also found if I put a , in front of the x, it assumes x is 0 and uses the first value and ignores the next comma and other value without throwing any errors. Doesn't matter, just more info in case it means anything to you.

sameer commented 1 month ago

I believe it's interpreting -7 as a flag and not an argument. Try putting it in quotes: '-7'.

That is what I was thinking. I tried ' and " for just the x and for both, no joy. Still does not like the -x. I also found if I put a , in front of the x, it assumes x is 0 and uses the first value and ignores the next comma and other value without throwing any errors. Doesn't matter, just more info in case it means anything to you.

Ok, this is a bit counterintuitive. The syntax is actually --origin="-7,0". The way the CLI parses args is a little outdated now. Things may have improved over the past 2-3 years so I'll look into upgrading that to see if it helps.

sameer commented 1 week ago

There is a new CLI release v0.0.17 that includes the fix for this. Fixed by 61f379ad204aee45d511e8ae073b4db33ad92dde.