An issue when opening LibreDWG (v0.13.3) generated DXF file.

[UgisL]

Hi,

I am trying to use exdxf to investigate and modify DXF files, which are obtained via the following workflow:

1. Architect creates a drawing with AutoCAD and saves it in a new DWG format (typically r2018);
2. The saved DWG file is converted via LibreDWG (v0.13.3) to r2004 DXF file;
3. I am trying to read and modify the created DXF file with the exdxf.

Steps to reproduce:

1. Use the attached 2018.dxf file as an example;
2. Try to read it with "doc = ezdxf.readfile('2018.dxf')".
   In my case, I get the following error:
   DXFTypeError: name has to be a string, got <class 'NoneType'>

For reference, I attach the original file (2018.dwg) as well. The LibreDWG command used to produce 2018.dxf is;
dwg2dxf.exe --as r2004 2018.dwg --file 2018.dxf

What I have found is that if I use the "-m" flag of LibreDWG, i.e. as
dwg2dxf.exe -m --as r2004 2018.dwg --file 2018_min.dxf
then reading the file (also attached for reference) via
doc = ezdxf.readfile('2018_min.dxf')
works fine.

I wonder if there is any hope to make reading of the full conversion output work? In this particular file it might not be very crucial, but I have other files, from which the "-m" flag actually strips a lot of information.

I have tried to use "recover" functionality:
doc, auditor = recover.readfile('2018.dxf')
but got the same error:
DXFTypeError: name has to be a string, got <class 'NoneType'>

Info about my system:
Win10Pro, Version 10.0.19045 Build 19045
Python 3.10.8 (tags/v3.10.8:aaaf517, Oct 11 2022, 16:50:30) [MSC v.1933 64 bit (AMD64)]
ezdxf.version -> (1, 3, 2, 'release')

All files attached in a single ZIP file:
2018.zip

[mozman]

Please report this issue to LibreDWG. Neither 2018.dxf nor 2018.dwg can be opened by Autodesk Trueview and therefore I consider these as invalid DXF/DWG files:

And I highly doubt any of these files was created by AutoCAD!

You can use the ezdxf browse command to investigate the 2018.dxf file:

You can clearly see the mandatory name tag with group code 2 is missing.

I will try to catch the exception, but I cannot recover such a file, because a BLOCK without a name is useless - maybe I just ignore such blocks.

[UgisL]

Interesting ... Thanks a lot for explanations and suggestions. I now also tried DXF files in TrueView and those indeed does not read, so then it probably is LibreDWG issue, I will report it to them. I was not aware of this issue because our own old importer seems to manage those, probably we are skipping unnamed BLOCKS.

The DWG file itself, though, is generated by Autodesk, at least that is what TrueView 2025 claims:

[mozman]

OK the 2018.dwg is a valid DWG file!

I have added a better error message for this case. But I have not found an easy way to fix or ignore such blocks, so the recover module still does not load this DXF file.

[UgisL]

Great, thanks! Perhaps a dumb idea, but could it work to assign some machine generated name to those blocks? Like "Nonameblock_x". I am guessing that these names often do not mean much ...

But will see what LibreDWG guys will say, perhaps they will find a solution.

[mozman]

This is not a stupid idea, because I had the same one 😄. But this has to be done at a very low level, before the main loop generates the DXF document, and for DXF R12 and later DXF versions in a different way. This is more work than I am willing to invest in a problem that should be fixed in the library that is causing this error. My conclusion: a DXFStructureError is good enough for this scenario.

[mozman]

@UgisL Just out of interest: why do you use LibreDWG and not the ODA File Converter?

[UgisL]

I see, ok, thanks for explanation. I was not aware of the complexity in adding name to the blocks! We have picked LibreDWG due to licensing questions. As I understand, ODA File Converter is only for non-commercial use, whereas GPLv3 LibreDWG can be used for commercial purposes.

[mozman]

@UgisL I revisited this issue and found a fix, so ezdxf can load this DXF file even without the recover module.

... good luck with the LibreDWG library, the audit process fixed 322 errors:

BricsCAD fixed 320 errors by the recover utility:

EDIT: If you want to save the loaded DXF you have to use the recover module to get the document into a valid state.

[UgisL]

Great, thanks a lot for supporting LibreDWG shortcomings ... I will take a note of the comments. Perhaps, eventually, we figure out a way to use the ODA converter as well, but for now we are putting in some efforts in LibreDWG direction.

[mozman]

I assume there is nothing further I need to do.