Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Visicut shows extra padding around object #720

Open
jnweiger opened this issue Apr 3, 2024 · 4 comments · May be fixed by #727
Open

Visicut shows extra padding around object #720

jnweiger opened this issue Apr 3, 2024 · 4 comments · May be fixed by #727
Labels

Comments

@jnweiger
Copy link
Contributor

jnweiger commented Apr 3, 2024

In inkscape I have drawn a numeral 3 (using hershey 1 line font)
The numeral is ca 4cm high, the viewbox fits very tightly.
For the screenshot, I pressed CTRL-A (select all) to demonstrate the effective bounding box:

grafik

When this SVG is sent to visicut (either via extension or save and load) it is shown with a huge padding.
This makes it difficult to set the starting point of the laser accurately.

grafik

Expected behaviour:

  • bunding box of the object in visicut is the exact bounding box.
  • viscut should not get confused by nested groups that stack several scalings and translations.

bb33.svg.zip
bb33

@mgmax
Copy link
Collaborator

mgmax commented Apr 26, 2024

Thanks for the good bugreport! Can you try to further simplify the example file?

Currently the file has five levels of groups, transforms etc., which will be quite difficult to debug.

@mgmax mgmax added the Bug label Apr 26, 2024
@jnweiger
Copy link
Contributor Author

jnweiger commented Apr 26, 2024

I've simplified the SVG file to one path with a scale transform. No nested groups needed.
The scale is a downscale by a factor of 1000, to emphasize the effect.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="40mm" height="30mm" viewBox="0 0 40 30">
  <path
     d="M 0,0 H 20000 L 5000,20000 h 10000"
     style="fill:none;stroke:#0000ff;stroke-width:100"
     transform="scale(0.001,0.001)"
     id="path4" />
</svg>

This figure Z is constucted with dimensions of 20000. The scale reduces this to 2 cm x 2 cm.
That much works identical in inkscape and in visicut.

The stroke width is set to 100; in inkscape the scale is correctly applied, resulting in an effective stroke width of 0.1mm

In visicut, the stroke width remain unaffected by the scale when doing the bounding box computation. That is a bug.

The bounding box computation includes sufficient padding to keep the entirety of an imaginary 100mm wide stroke inside the bounding box. We get 50 mm added to each side, resulting in a 12 cm x 12 cm area with the Z in the center.
When drawing the path, the stroke width is correctly scaled, though.

image

image

@jnweiger
Copy link
Contributor Author

BTW: In inkscape there is a switch, visual bouning box / geometric bouning box, I ususall choose the latter, so that stroke widths do not distort object sizes.
Visicut seems to have visual bounding box hardcoded, otherwise this bug would have no effect.
This also means, that thickening the lines in inkscape, moves the drawing in visicut by half the added stroke width.
That is probably a surprise to most users...

mgmax added a commit to mgmax/VisiCut that referenced this issue Apr 27, 2024
For `<path transform="..." style="stroke-width:...">`, VisiCut ignored the `transform` when calculating the effective stroke width that is used to determine the bounding box.

As a result, some files showed way too large bounding boxes and could not be moved fully to the top left.
@mgmax mgmax linked a pull request Apr 27, 2024 that will close this issue
mgmax added a commit to mgmax/VisiCut that referenced this issue Apr 27, 2024
For `<path transform="..." style="stroke-width:...">`, VisiCut ignored the `transform` when calculating the effective stroke width that is used to determine the bounding box.

As a result, some files showed way too large bounding boxes and could not be moved fully to the top left.
@mgmax
Copy link
Collaborator

mgmax commented Apr 27, 2024

With #727 it should hopefully be better. I didn't test it in detail, maybe it is still wrong for some special case.

Now the stroke width is computed correctly, although we need it only for engraving ("visual bounding box") and not for cutting ("geometric bounding box"). Please create a separate issue for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants