haplokuon / netDxf

.net dxf Reader-Writer
MIT License
993 stars 404 forks source link

Two issues with LibreCAD DXF import #439

Open mikau16 opened 1 year ago

mikau16 commented 1 year ago

Issue 1: I had a version of NetDXF that was a few months old. I was able to read exports from LibreCAD just fine. Today I upgraded to the latest. The import crashes with a failed assertion. Attached is the DXF file imported from LibreCAD: closedSpline1.dxf, and a screenshot of the location of the failed assertion.

LibreCAD is free, fyi, I am testing on Version: 2.2.0.

Issue 2: The reason I was upgrading was I noticed a bug with the closed spline evaluator, and wanted to see if getting latest would fix it. I am the one who wrote the original NURBS evaluator (that is, the Spline.ToPolyline2D() method). It seems to work okay for open splines but I see some changes were made to handle closed or periodic splines, and that seems to be not behaving correctly here. Its possible this is due LibreCAD doing something unorthodox, but I don't know. I'd be willing to help try to debug, but I'd need Issue 1 resolved first. Attached is a screenshot of the discrepancy between the LibreCAD and NetDXF calculated splines. LibreCAD_NetDxf_Issues_Docs.zip

haplokuon commented 1 year ago

At the moment and for a while I will not be able to take a deep look into this. But here are a few tips.

If the code raises and assertion that means that you are using a Debug build not a Release build. Assertions, not Exceptions, are used in the code, to check for things that should not happen but are fixed or a workaround has been applied. I use them to keep track of weird things just in case they might raise a more serious problem down the line. You should not worry about them, they are for debugging purposes, and can be bypassed without problems. Use the Release build.

I tried to load your DXF with Autodesk DWG TrueView 2020 and it shows the same result as netDxf. in the "ClosedSplineError.jpg", also does QCad; so, the problem must be with LibreCAD.

In case of doubt, always try the DWG TrueView, it only lets you see the DXF but at least is also free. That application is from Autodesk and for better or worse they are the ones that establish the rules.

mikau16 commented 1 year ago

Thanks for the very quick reply. Wow, you're right. It does seem to unique to LibreCAD. That's a relief.

I was indeed using a debug version. But I don't have an urgent need to upgrade if there is no actual problem with the NURBs evaluator. So don't rush to fix Issue 1 on my account.

Thanks again.

haplokuon commented 1 year ago

There is nothing to fix in your Issue 1, it is a warning not an error, use the Release build and it will be fine.

mikau16 commented 1 year ago

There is nothing to fix in your Issue 1, it is a warning not an error, use the Release build and it will be fine.

When you said "At the moment and for a while I will not be able to take a deep look into this." I assumed you were referring to Issue 1 since Issue 2 appears to be the fault of LiberCAD. Are you saying you are going to look further into issue 2 to see if there is some minor nuance to the LiberCAD exports that you can detect to make it load correctly?

haplokuon commented 1 year ago

I was referring at that I do not have time to know what is the exact problem with the LibreCAD DXF, and why it is behaving that way. I do not even know if I can add a workaround, what it is clear is that LibreCAD is not working as it should.

The assertion that was raised is related with reading a handle value that was not properly written, I doubt it is related with the spline issue but since I did not check it I cannot be 100% sure. Probably, LibreCAD wrote a table object name where the handle was expected, it is not the first time I have seen this kind of issues.

DavidWishengrad commented 1 year ago

mikau16, I have not tried that spline code yet, but thank you for it. That's a bit over my math skills atm. I suggest contacting LibreCAD with the issue so they can fix the dxf output. You can probably present it better to them than most. Also, I don't honestly know better, so please educate me, why is it that if a work-around can be done in the netDXF, even just temporarily, that you cannot modify the source yourself? Can't you just skip a corrupted entity or handle or whatever and treat it like it was never mentioned and still open the dxf without the item or correct what is really needed right there on the fly, even with anonymous data? Seems weird, but again, I don't know and is why I am asking. There are a lot of people who could use some code that fixes these weird dxf's enough to get them open. Needless to say, the hard responsibilities fall clearly on the software doing the export and they should want to get their bugs fixed.

Thanks

mikau16 commented 1 year ago

"Also, I don't honestly know better, so please educate me, why is it that if a work-around can be done in the netDXF, even just temporarily, that you cannot modify the source yourself?" I understand NURBs enough to implement an open spline evaluator, and that's the portion I contributed in the first implementation, but the precise details of how the closed/periodic splines are handled is still a a bit of a mystery to me. I originally wondered if whoever extended my code to handle the closed/periodic cases might know what was wrong. But as haplokuon observed, it seems to be LibreCAD at fault and the NetDXF implementation is probably correct. I'd be happy to implement a work-around, I just don't know what that workaround would be yet. For now I have contacted the folks at LibreCAD. Maybe they can give me some specifics on what its doing.

DavidWishengrad commented 1 year ago

Thank you! That makes perfect sense to me.