Update margins for Cameo 1

[miLORD1337]

Offset for Cameo 1 was too high previously, as e.g. discussed in #15

[t0b3]

@tiger12506 can you give your review in this PR?

[tiger12506]

Unfortunately, there is more to it than just this.

You can see (0,0) origin point in the upper left. The test file has 4 squares, each 10mm, in each of the 4 corners of the cutting mat.

In main branch, I have the user-configurable offsets set to 0mm, 0mm. That results in the square in the origin corner being above and left of the cutting mat origin, and the full 10mm square can be see in the lower-right corner, because it is shifted well into the cutting region (about 2mm,5mm).
I didn't switch branches. I don't know what I was thinking. Both of the tests are in patch-1 branch, one with the (0mm, 0mm) user-configurable offset, and the second test with a (2mm, 5mm) offset. Ugh. I can do the test from scratch if you need certainty on the process.

So, I shift to this branch, miLORD1337/patch-1. Now, the origin square is correct (with a user-configurable offset of 2mm,5mm), but the squares at the bottom-left and bottom-right are incorrectly foreshortened.

I assume what's happening is that, although I can adjust the user offset (and the hardcoded offsets also) to move the design to the proper location of the cutting mat, but the offsets do not have an effect on the code which clips the design ("Trim margins" is off, "Enable Software Clipping" is also off). I haven't looked closely at the code, but I would assume that a virtual buffer is created which encapsulates the design, but it doesn't take into account the offsets when doing so, and therefore doesn't haven't enough space for the shifted design when doing conversion to cut code.

Let me know if there is anyway that I can help resolve this, with a listing of some tests to do. I would like to get this resolved correctly, not only for me, but for the sake of inkscape-silhouette.

[tiger12506]

The SVG file I tested with.

[miLORD1337]

Okay, I'm not sure I can follow... For me, my patch makes (0,0) appear at (0,0) on the cutting mat with (0mm, 0mm) user-configurable offset. Are you saying it only is correct for you when you use a (2mm, 5mm) offset?

I'd like to not worry about the bottom (yet), as that is a different problem and I'm not sure about your test procedure. Things to check:

• User offset set to (0 mm, 0 mm)?
• Is the square placed at y = 12 in - 10 mm?
• Is the 12x12 cutting mat selected?
  I think cutting at y < 0 or y > 12 in is mitigated by the machine itself. Maybe the same is true for x when 12x12 is selected? Therefore, please also try 12x24 and see if that works.

[miLORD1337]

I just tried cutting at exactly (0,0) and it only cut the two inner lines of the square. If the square is moved ever so slightly, it works. And cutting at exactly 12 in x or y is the same, doesn't work. But ever so slightly moved inwards, it works.

So I can say for sure that no problem in proportion to the length of cut exists on my machine. The squares are cut exactly were I placed them digitally.

This is what I wanted to solve with this PR. Could you please confirm again? I know for some cuts near the edge things can be annoying, but that is out of the scope of this PR I think and it's already quite an improvement.

[tiger12506]

Okay, I'm not sure I can follow... For me, my patch makes (0,0) appear at (0,0) on the cutting mat with (0mm, 0mm) user-configurable offset. Are you saying it only is correct for you when you use a (2mm, 5mm) offset?

Yes, but for me the offset really isn't the issue at all. Think about it, you can manually place the cutting mat in slightly different positions, and your offset would be wrong. Unless we are getting out the calipers and carefully placing our mats the exact same position from the endstops, we will never determine a "correct" offset.
Since I was using a Cricut cutting mat for that test instead of a Silhouette mat, my offset would be completely invalid anyway. But that's not the issue.

I'd like to not worry about the bottom (yet), as that is a different problem and I'm not sure about your test procedure. Things to check:

* User offset set to (0 mm, 0 mm)?

No, user offset set to 0mm, 0mm is off the mat for me (again, might be a cricut mat issue. Not my concern)

* Is the square placed at y = 12 in - 10 mm?

Yes, I sent the svg. There are 4 squares, (0,0) -> (10mm,10mm), (12in-10mm,0) -> (12in,10mm), (12in-10mm, 0) -> (12in, 10mm), (12in-10mm, 12in-10mm) -> (12in, 12in)

* Is the 12x12 cutting mat selected?

I think so... would have to check.

  I _think_ cutting at y < 0 or y > 12 in is mitigated by the machine itself. Maybe the same is true for x when 12x12 is selected? Therefore, please also try 12x24 and see if that works.

To some extent, yes, but I believe there to be a bug regardless. Silhouette Studio by default will have margins on a 12inx12in cutting mat, but you can change the preference to have no margins, and it works.

My issue with inkscape-silhouette is that clipping is happening in a way that doesn't respect the offset at all. Sure, if you had (0,0) user offset, then it would work correctly (I cannot actually confirm this as (0,0) is outside the working area of the mat for me)-- it would just be in the wrong place. Thus defeating the purpose of the offset entirely. So, the issue is not that the offset is wrong. The issue is that applying an offset (that I need) cannot produce a valid result (for me).

I will need to run the tests again.

[t0b3]

@tiger12506 @miLORD1337 in case it's hard to explain the settings you apply for that use case:

• you may post the full command line call (it'll be logged in case you choose so and can be read from your logs)
• that command can then easily be reproduced and tested by other users using the command line

Hope this helps to clarify soon with this
see also https://github.com/fablabnbg/inkscape-silhouette?tab=readme-ov-file#cli