SVG output is forced into pixel dimensions

[ArmoredBlood]

I'm working on revamping the SVG exporter so the SVG output is actually useful for CNC operations such as laser cutters, potters, and routers/mills.

Currently, the svg exporter outputs a fixed orientation with a static, hardcoded triad (origin marker). It also scales the output to fit inside hardcoded pixel dimensions, with the option for custom pixel dimensions.

My current plan (i.e. what I already have implemented) is to expose the basic "views" that are seen in cq-editor and freecad: front, back, left, right, top, bottom, isometric, and a "legacy" view which is the current hardcoded perspective.

The bigger question (the reason I'm opening this issue for discussion) is that I'd like to remove (or somehow optionalize) the pixel dimensions from the svg output and let it output actual dimensions to the file. That way, the user can immediately import the svg into cam software without any additional work.

I'm currently working out how to get around the scaling and to let the size of the model dictate the size of the resulting svg file.

I don't see the value in a non-dimensionally accurate, scaled down SVG of my model with a static triad that doesn't rotate with the object.

What are your thoughts on that?

[dcowden]

Your approach sounds good to me. I am likely the author of the original legacy view. The objective of the SVG output at the time was in the very early days of CQ, when the primary objective was to put a picture into the sphinx docs. I used the docs as a way to visually check that the models were correct ( which, BTW, is still very valid-- a human an check pictures for accuracy amazingly quickly ) Anyway, there's still a need to produce an SVG that is suitable for pictorial display-- you're keeping the legacy view, so that'd handle that requirement. It might be cool if you can output svg with the right units, but then have a parameter you can pass in that gives the size in px you want-- then it's scaled. that, combined with selection of views as you have discussed, would produce the legacy view without having another set of code still hanging around. thanks for contributing the work to make CNC-capable stuff, that's awesome!

…

On Mon, Oct 19, 2020 at 9:33 AM Aaron Peterson ***@***.***> wrote: I'm working on revamping the SVG exporter so the SVG output is actually useful for CNC operations such as laser cutters, potters, and routers/mills. Currently, the svg exporter outputs a fixed orientation with a static, hardcoded triad (origin marker). It also scales the output to fit inside hardcoded pixel dimensions, with the option for custom pixel dimensions. My current plan (i.e. what I already have implemented) is to expose the basic "views" that are seen in cq-editor and freecad: front, back, left, right, top, bottom, isometric, and a "legacy" view which is the current hardcoded perspective. The bigger question (the reason I'm opening this issue for discussion) is that I'd like to remove (or somehow optionalize) the pixel dimensions from the svg output and let it output actual dimensions to the file. That way, the user can immediately import the svg into cam software without any additional work. I'm currently working out how to get around the scaling and to let the size of the model dictate the size of the resulting svg file. I don't see the value in a non-dimensionally accurate, scaled down SVG of my model with a static triad that doesn't rotate with the object. What are your thoughts on that? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#487>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ44AYB7PKCKMZ7DLS2W23SLQ5Z5ANCNFSM4SWE5QVQ> .

[ArmoredBlood]

That's a very valid use case that I hadn't thought of. In that case, I'll try to figure out a clean way to accomodate both processes.

[dcowden]

@ArmoredBlood great!

FWIW, the example docs for which i originally wrote the SVG view now use a much fancier interactive display, so i'm not sure anyone actually uses the legacy view any more

[ArmoredBlood]

@adam-urbanczyk any idea if we still need to support the legacy view and the scaled pixel dimensions? It's a lot of code that can be removed if it's not being used for anything

[adam-urbanczyk]

@ArmoredBlood I was under the impression that you just wanted to expose more parameters for SVG and not change it into smth else. As already mentioned current SVG export is used to generate documents (e.g. pdfs, slide decks). https://github.com/ukaea/paramak is for sure using it, and I'm also using this functionality. So I'd say it has to definitely stay.

CQ currently supports exporting to DXF which I think is a better format than SVG for CAM related work (due to the fact that it supports NURBS). What is actually missing there? Most likely it'll be much easier to fix that, than do double work on SVG.

Last but not least, current SVG export uses simple line segment discretization. Are you sure you want to use that for CAM, or were you planning to implement a better solution?

---

You did mention the CAM thing in #486 - I somehow missed the motivation.

[ArmoredBlood]

We have a vinyl cutter at our makerspace with software that doesn't take DXF, at least not in the version tier we have. I've ran into issues using DXF in some other open source workflows that aren't engineering specific, whether it was an issue on the file producer side or the consuming software side. That's the driving force behind this change for me.

Specifically I'm thinking of my laser cutter workflow at the makerspace. I have no engineering background so I don't fully understand the nuances of DXF over SVG. I do know how to edit/manipulate an SVG if needed using readily available tools. You're probably right that DXF is the better format for router CAM though.

With that said, I think it would be a good enhancement for CQ to be able to output SVG's in the format I described. If it's the completely wrong direction for the project though I would understand. I just think this feature would enable more creative uses for CQ than proper engineering.

[dcowden]

I agree SVG is worth the work-- @adam-urbanczyk is right that there's a lot of overlap with DXF, but it's serving a different community, I think. The mechanical/CAD types will use DXF, and have the tools to do so, but the maker/small time makers will tend to prefer cheaper tools ( IE, NOT $100/mo autocad/solidworks/onshape).

@adam-urbanczyk is also right that SVG done right would write arcs not line segments, which is sort of fiddly. Another fiddly optimization is to make sure you represent edge loops as connected polylines, so that you dont have rounding error on the segments. DXF actually allows you to do ie either way, and DXF files that have lots of tiny line segments with gaps between the ends due to rounding error are something i encounter a lot-- people are always wanting tools to fix that.

[adam-urbanczyk]

It sounds to me that you just need a good DXF converter @ArmoredBlood. I'd start here: https://qcad.org/en/qcad-command-line-tools . As already mentioned, it might be more work than you think to get proper SVG for your application.

[ArmoredBlood]

I'm not too concerned about the amount of work. I really like CQ and wanted to start contributing where I could to help make it better so I started working through old issues so I could get familiar with the codebase.

I don't have an immediate need for proper svg output, but I think CQ could benefit from having it in the future.

If not this enhancement, is there somewhere else you'd like to direct my effort? Or is there a more informal place to ask these sorts of questions?

[adam-urbanczyk]

Don't get me wrong, if you want to improve the current SVG output capabilities, then you are more then welcome to do so! I just wanted to point out what is already possible.

[jmwright]

@ArmoredBlood I'd say if SVG export interests you and plays to your strengths/experience, go for it. As @adam-urbanczyk has noted though, backward compatibility will need to be maintained if at all possible. We'd have to go through a deprecation process if anything is deemed important enough to break backwards compatibility. We'd want to have that discussion before you spend a lot of your time on a breaking change to make sure the team is willing to approve it.

I think that having something real-world like the vinyl cutter to test the SVG exports against would be very helpful.

[ArmoredBlood]

Sounds good. And no worries! I want to be a good member of the group as didn't want to step on any toes. I'll continue working on this feature then since I've made some good progress on it. I will probably finish this enhancement and put it all behind a parameter in the new options dict. Then I'll take a stab at improving the actual svg output file in a separate PR. I've never dealt with the inner workings of an svg file before so that will be fun to learn. Thanks for the input!