Sebastian Kuzminsky

Results 28 comments of Sebastian Kuzminsky

> This add author name to the list. I don't understand this comment. This change means we now have a build dependency on git-buildpackage, right?

> the text placed in d/changelog is slightly different, with [Author Name] placed in front of each list of changes Ah thanks, that clears up my confusion. > Yes, when...

I agree we should avoid forking external software into the pycam repo. I'm focusing on the debian packaging of pycam, and there it's easy to pull in external libraries and...

Clipper/libpolyclipping looks good in many ways, however it has a limitation that I don't like: it apparently only handles straight lines, not arcs. We could work around this by replacing...

I've spent the past several weeks playing with https://github.com/mathandy/svgpathtools. It's a pure python module that reads SVG files and parses the paths into an internal representation. The path itself and...

The pocketing is implemented in a program called `svg2gcode`, in this repo: https://github.com/SebKuzminsky/svg2gcode It's super quick and hacky, and not really intended for anything other than me playing with svgpathtools...

svgpathtools does not currently include polygon offsetting, though it does include primitives from which polygon offsetting can be implemented. I've sketched out a polygon offsetting function based on svgpathtools, but...

@ebo Yes exactly, the offset polygon consists of the parallel curve (with a specific distance) of the original polygon. It's used for tool radius compensation, and it can also be...

One thing I like about svgpathtools is that it supports all the path segment types of SVG: lines, elliptic arcs, and quadratic and cubic bezier splines. Arcs especially are common...

The bugs i've found in svgpathtools (so far...) are: * mathandy/svgpathtools#35 * mathandy/svgpathtools#37 * mathandy/svgpathtools#41 * mathandy/svgpathtools#43 I fixed some of those issues and offered PRs, but they have not...