This project has moved. For the latest updates, please go here.

Reader bug or is this DXF file just corrupt?

Jul 2, 2014 at 4:44 AM
Edited Jul 2, 2014 at 4:52 AM
So my software makes use of NetDXF and thus far has been pretty reliable. One of my users recently sent me a file that failed to open. I assumed it was a parsing error on my part but turned out NetDXF couldn't even open the file. I attempted to open the file in DraftSight and it also failed to open the file.

Here is a link to the file:
DXF file

I did however peek at the file using an online DXF viewer and it was successfully opened:

Any idea what the issue could be?

Jul 2, 2014 at 2:24 PM
First your file is an AutoCad14 dxf database version, this library only supports AutoCad2000 version and above. It is recommended to prior to loading a file, check if it is a valid dxf, with something like:
DxfVersion version = DxfDocument.CheckDxfFileVersion("gear18B.dxf");
This will return the dxf version of your file and, if it is AutoCad2000 and above the library should be able to read it. If it returns Unknown, the file is anything but a text based dxf. A binary dxf will always return Unknown since, at the moment, they are not supported.

But it is not here where the main problem with your file lies, the short answer is, it is corrupt.

Looking inside, it contains one single spline entity that has a value for code 72 (number of knots) of -25532, and a value for code 73 (number of control points) of -25536, as you can see those values are totally wrong, they must be positive; it really has 40004 knot values and 40000 control points, it does not even coincide with the absolute value of code 72 or 73.

I tried to open the file with other programs and only AutoCad was able to read it, I guess it does not use the codes 72 and 73 to build the spline. Now, netDxf is only making use of the value store in code 72 and, therefore, will also fail with errors like this. I will change this just in case.

Aug 12, 2014 at 6:45 PM
Edited Aug 12, 2014 at 6:47 PM
Sorry I forgot to thank you for your response on this, Daniel! That version check is very useful information for me.

I have another file which is puzzling me. This one is a version 2012 DXF but the reader is failing to open it. My users keep sending me all sorts of weird and wonderful DXF files, usually I tell them I can't do anything if the dxf won't open in most software, but in this case its opening in pretty much everything else, but not NetDXF.

DXF File

Select the file "Ova-2-1".
Aug 13, 2014 at 5:16 PM
There is nothing wrong in your "Ova-2-l-created in RhinoV4-aug 11,2014.dxf" file, it is just a bunch of lines; but, it is an AutoCad12 dxf file not an AutoCad2012; actually, such dxf revision does not exist, not for every AutoCad version there is a dxf database version.

Working with the binary dxfs I found the exact problem with your previous file. It is a combination of Autodesk stupidity and a buggy dxf exporter. If you convert the number of knots 40004 to a short you get exactly -25532, even if such conversion should not be possible. Same thing happens with the number of control points. According to the dxf documentation a spline entity is limited in the number of knots and control points to a short, since those values are controlled by the codes 72 and 73 (16-bit integer value, a short in net) the maximum number of elements should be 32,767. AutoCad seems perfectly fine of handling larger number of control points and knots, at least on latest versions I cannot test every single one, so to avoid such problem it does not care of what it is written in those values. AutoCad also makes the same mistake of writing negative values in those fields. Summing up I will not recommend working with such large sets of knots and control points, if you need so many to draw something you are doing something wrong to begin with. Will it be an ushort? Who knows, but I ain't gonna try it.

The worst part in all of this is that Autodesk does not even care of documenting such things, and the dxf format is full of this crap.