I didn’t pay attention to my line width and cut this very delicate design on accident. It stayed together, so I put it high on the wall where no one could bump it.
The outer lines are so thin they almost disappear when viewed head-on, but they cast crisp shadows from any other angle and manage to stand out all the way across the room.
I think you could go thinner. 
haha
Looks cool!
I am not sure what you mean here… the 
ignores stroke-width. “Kerf” (the width that is vaporized or burned) in the material is controlled by power/speed, not the width of the lines in the SVG.
(Cool result though!)
Yeah, I have watched with dismay as thin sections in a design vaporized. 
If you fiddle with settings you can get some really delicate cuts without over-charring them. I spent a lot of time exploring this a while back.
I intentionally went as thin as possible on a design and found 0.015 as the thinnest I could do. Any smidgen smaller and it looked okay until you touched it and it just crumbled to dust.
I have more tricks now and could probably manage the heat better, but 0.015 worked for me.
Those look about there, but since there is no flat spot to measure I suspect squeezing calipers to measure it would destroy the thing .
Looks great hanging there.
I think OP is referring to stroke width when the stroke is converted to path.
1mm stoke width to path would result in 0.75mm final “cut” path. The kerf would be 0.25mm. This is something I have tried with maps where the streets are cut not engraved. the lowest I could go to was 0.75mm stroke but the streets are too thin, break and cleaning up is a huge headache. in my opinion very thin paths result in some loss of proportionality, aesthetically not very good at least for maps.
Unless used in a dense lattice like structure, then they would look very intricate and cool. just my 2 cents. 
Yes, I assumed that too.
I don’t think stroke-width is used in any part of the calculations the uses to create the cut. You could set your stroke-width to 50mm and it wouldn’t care.
Take this file for example. I have increased the border width to 20mm.
But when it is loaded into the GFUI, this is what you get:
It completely ignored the width of the stroke on that line that made the border.
I don’t think stroke-width is used in any part of the calculations the
Yes, you are correct stroke width doesn’t matter for the GF.
But our discussion is at the pre-GF stage, this is an issue with the design even before it is cut on the GF. The way OPs design is cut in the image, the path cut out is a design feature. OP likely didn’t pay attention to the default stroke width in Inkscape, lets say it is x mm. So when OP converts the design to cut (stroke-to-path menu) the path width becomes x mm. uploading this svg would result in a material thickness of (x-kerf) mm irrespective of what the assigned stroke width (e.g., 50mm) is in the uploaded file.
After re-reading my initial response I realize that my response referred to SVG design not to GF cutting per se, sorry for the confusion.
I understand converting original designs and how width between paths can be created (like the OP is talking about).
What confuses me is when you mention a “1mm stoke width” then claim “the kerf would be 0.25mm”?
I was only trying to point out that the “stroke-width” of the path has zero correlation to the “kerf” resulting from the cut. That is all controlled by the material type and the power/speed setting used in the GFUI.
I was only trying to point out that the “stroke-width” of the path has zero correlation to the “kerf” resulting from the cut. That is all controlled by the material type and the power/speed setting used in the GFUI.
For a final product like in the image OP attached, both stroke width (used at the design stage) and kerf (actual laser cut on the GF) are important.
I see where our misunderstanding is coming from. You are referring to “stroke width” of a tool in a design program. I am referring to “stroke-width” a property on the XML path.
“Stroke width” would completely be relevant in the design process for drawing.
“stroke-width” value in the resulting SVG XML would be completely ignored.
Please forgive my misunderstanding. I used to write all my SVG files in a text editor, instead of in a visual designer, so I often relate to actual SVG XML semantics.
Some accidents are great accomplishments.
True dat! Looks awesome
