Managing not regular dxf file

Apr 26, 2015 at 8:27 PM
Edited May 4, 2015 at 7:58 PM
I added some fixes to let DxfReader opens dxf files when exists layouts with object handle "0" ( removed layout ), blocks without layer defined ( assume "0" layer ) and avoid to add layout when they are null.

These happens to me opening some dxf files that not conform but consider that regular dxf viewers open these files without issues.

Watch the changes at follow url if you find something useful to merge LINK
Apr 27, 2015 at 4:10 PM
May I see a sample file where this is happening? It is very strange to see a layout with a handle "0", this should never happen. I have never seen such a case, which program has generated that file? Whenever I made a mistake with the object handles I get a crash in AutoCad. Sometimes I have seen handles "0" in soft pointers, but it is like referencing to null.

May 4, 2015 at 7:58 PM
Hi Daniel,

sorry for my late response,
here a simple dxf file with one block inserted ( the block omits the layer definition )

and here another with a null layout ( note that with old version of cad crashes but within newer viewer you can open it without problem )

consider that these two files are not conform, I said :) and these are not generated by the netDxf library,
so every adjustment is a plus and only useful to open such dxf file generated from not so good dxf libraries.

More I would to notify you the behavior of the ReadObjects() in the case of the Layout
case DxfObjectCode.Layout:
                        Layout layout = this.ReadLayout();
                        this.doc.Layouts.Add(layout, false);
when there is the call to the ReadLayout() as for the follow line of the function body we can have null on returned value :
// if the layout has an invalid block record discard it
            if (ownerRecord == null)
                return null;
so that I suggest to manage in some way this because null layout will except null pointer usage on the following
 Layout add;
            if (this.list.TryGetValue(layout.Name, out add)) // layout.Name when layout null
                return add;
May 6, 2015 at 6:25 PM
The first problem with the block layer has an easy fix. I should have given a default value to the layer like in many other similar places, somehow it slipped through. For a lot of values is correct to avoid writing them when they are the default, this conforms with the dxf format.

The problem with the layout is a lot worse, not only the layout has a wrong handle for the soft id that should have pointed to its associated block record, but also this one points to the wrong place. This is a serious bug with the program that wrote the file, it can yield to unpredictable outcomes. I tried to load it with the last version of AutoCad, 2016; and while it was able to read it, as soon as you change layouts the program crashes. I guess that cad viewers that only handle with ModelSpace entities, do not show any ill behavior, this bug is in the *PaperSpace block record and layout.

I have added code to try to relink orphan layouts with its Model/PaperSpace block record, and vice verse. Simply discard the layout is not a good solution, it leads to undesirable results. This is the reason why it is much better to open an issue in the project including a sample so I can reproduce the bug. I will include this workaround in the next update, soon.

About all your dimension style variables additions. You cannot add them without also modifying the way the dimensions are drawn, that is the important change. Again for the next update, you will be able to draw dimensions with any of the available units defined in the DIMLUNIT and DIMAUNIT, so it will be possible to write length units in Architectural, Engineering,...; or angle units like Degrees/Minutes/Seconds, Radians,... format. For this kind of things making simple request to include a particular feature is good enough, and I will see what I can do, instead of writing incomplete patches.