CLI --output syntax is counterintuitive

[MadTooler]

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? 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]

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]

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 e50e42b. The web UI should be up to date now.

[MadTooler]

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]

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]

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]

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]

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]

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]

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