@WickedSmoke I merged 32bcc1f, 7b22cc1 and 5109b26
as: c9e5239, b4a7973 and 9aa4426.

Thank you!

I dropped 6e4d451 because I think we should just update libdxfrw to the latest one, I did this in a quick and dirty way local, and it works but we have many, many SolveSpace specific changes in our fork and I need to carefully review them.

@ruevs note that b4a7973 is actually incorrect in light of 495b203 (which you committed in the mean time in #1518), as there's no fall through anymore.

the libdxfrw situation is not great. I went through and fixed a ton of clang-tidy-discovered issues at one point, but didn't do it on the right fork or branch or something... I'm not sure why ours differs from upstream, I think upstream was/is inactive? Anyway not great.

I think the changes themselves look fine, though. Probably drop the dxfrw and fix the issue noted above.

Keep in mind the path forward is hopefully to drop dxfrw entirely in favor of [libredwg](url) which has already been mostly? integrated. Anyone wanting to pick that up and close out our dxf issues give it a try.

@ruevs note that b4a7973 is actually incorrect in light of 495b203 (which you committed in the mean time in #1518), as there's no fall through anymore.

Thank you @iscgar - you are correct. I reverted the commit.

Keep in mind the path forward is hopefully to drop dxfrw entirely in favor of [libredwg](url) which has already been mostly? integrated. Anyone wanting to pick that up and close out our dxf issues give it a try.

That is true. But until someone using DXF/DWG files (I am not) and willing to work on it comes along the best I can do is update to the latest libdxfrw and selectively apply the many local patches we have.

@ruevs with the merging of your work on libdxfrw in #1615, the last unmerged commit from this PR is not needed anymore, so I think it can be closed.

Indeed. Closing.