Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DXF file generated by running dwg2dxf cannot be opened by AutoCAD #19

Open
cqwuxiaolong opened this issue Dec 1, 2020 · 11 comments
Open
Assignees
Labels

Comments

@cqwuxiaolong
Copy link

cqwuxiaolong commented Dec 1, 2020

I use AutoCAD to draw a random drawing and save it as DWG. The DXF file generated by running DWG 2dxf cannot be opened by AutoCAD. If you open it with notpad + +, you will see a lot of black "NUL". There is no such "NUL" in DXF generated by AutoCAD.

@lordofbikes
Copy link
Member

Can you share these files please?
When you pack them into a ZIP archive, you can paste it here.

@Guruprasad-Rane
Copy link

Guruprasad-Rane commented May 21, 2021

Faced similar problem. DXF file generated by libdxfrw can not be opened in XED text editor. This is due to NULL characters at some places.
dwg2dxf.tar.gz

This issue can was solved by adding t=t.c_str(); in the following function in dxfwritter.cpp I am not sure whether it is a correct approach but it removed thee trailing NULL character.

bool dxfWriter::writeUtf8String(int code, std::string text) {
    std::string t = encoder.fromUtf8(text);
    t = t.c_str();
    return writeString(code, t);
}

dwg2dxf after fixing.tar.gz

@lordofbikes
Copy link
Member

@Guruprasad-Rane this issue is about dwg2dxf, did you also use it when the problem happened to you?
From my understanding dwg2dxf is not a ready to use file converter, it is more an example for how to use libdxfrw.
As this doesn't happen in LibreCAD 2/3, I must assume an issue in dwg2dxf or it uses functionality which is not used by LibreCAD.
Anyhow, when the example is buggy, we should solve it.
Many thanks @Guruprasad-Rane for pointing out a solution. I have to take a look into sources to understand the issue and evaluate if your solution is appropriate.

@lordofbikes lordofbikes self-assigned this May 22, 2021
@Guruprasad-Rane
Copy link

@lordofbikes Yes, I was using dwg2dxf when this issue happen.

@UnfinishedBusiness
Copy link

Does anyone know why this is? I'm using libdxfrw to export DXF files. The DXF files that are exported are opening fine in LightBurn, SheetCAM, and most online tools but they will not open in any Autodesk products. Fusion simply says failed to open DXF file or something similar to this without any useful explanation.

@ferrellsl
Copy link

ferrellsl commented Jan 26, 2022

I have the same problem. The DXF files generated with dwg2dxf open without issue using ProgeCAD and other apps, but fail to load with AutoCAD. I'm using version AutoCAD 2020. When I audit the DXFs in ProgeCAD, ProgeCAD reports the following issue but still loads the file without any other complaints: AcDbLayerTableRecord(10), PlotStyleName Id (F), Validation: , Replaced by: <Set to Null>

Not sure if the above info is what's causing the AutoCAD load failure or not. I've also attempted to use AutoCAD's recover command on the DXF files but the recover command fails without any error messages at all.

@ferrellsl
Copy link

I seem to have found a fix. Since AutoCAD's recover command was failing I decided to use the CLASSICINSERT command to see what errors were produced. CLASSICINSERT complained about the $HANDSEED value of 20000 being too low and to edit the file and change the value to 20001. I did this a few times and each successive insert failed with the same message and to add another 1 to the handseed value. So, I decided to change the handseed value to something enormous and it worked. I just added an additional zero to the value making it 200000 and it now loads.

@ferrellsl
Copy link

ferrellsl commented Jan 26, 2022

I just confirmed that editing line 913 of drw_header.cpp and changing the value to 200000 eliminates the AutoCAD load problem for me.

CLASSICINSERT now works without any issues.

Edited line should read: writer->writeString(5, "XXXXXX");

Replace the X's with the hex number that you want to use. Make sure it's the same size as the number of entities in your DXF file or slightly larger and then recompile. Another option is to just edit your DXF file and change the handseed value there and save it.

Ideally, this library and/or the dwg2dxf program should calculate the correct handseed value for the user rather than using an arbitrary, hardcoded value of 20000 hex (131,072 decimal).

@zxcv8553172
Copy link

I have the same problem,too. autoCAD2020 and autoCAD2007 can't open dwg2dxf or dxf2dxf that autoCAD tell me Press Enter continue. If press Enter, my dxf file is close. Who can solve this problem?

@lordofbikes
Copy link
Member

As already mentioned, this can't be solved without a sample to reproduce the issue. That means the DWG and converted DXF files.
Also the reasons for failing in AutoCAD can be various, it is not necessary the same cause.
From Autodesk TrueView I know, that there is an error message, usually showing a line number and explaining the issue. The message is in the output panel, where the Press Enter prompt appear, it can be expanded and scrolled.

@zxcv8553172
Copy link

As already mentioned, this can't be solved without a sample to reproduce the issue. That means the DWG and converted DXF files. Also the reasons for failing in AutoCAD can be various, it is not necessary the same cause. From Autodesk TrueView I know, that there is an error message, usually showing a line number and explaining the issue. The message is in the output panel, where the Press Enter prompt appear, it can be expanded and scrolled.

A sample I give you,
errorDxf2Dxf.zip
autoCAD tell me Error in APPID Table.

mlight-lee pushed a commit to mlight-lee/libdxfrw that referenced this issue Feb 17, 2025
* Add improved CMake buildsystem.

* Delete all allocated items in destructors.

* Read and write knot weights in DRW_Spline.

* Add forgotten initialization for DRW_Dimension::length.

* Set $DIMSCALE default value to 1.0.

The old value was likely a copy-paste error.

* Don't write $DIMTXSTY (handle of referenced STYLE) by default.

QCad doesn't display any dimensions where it's set.

* Adjust DRW_Dimstyle defaults to match DRW_Header::write.

* Initialize DRW dimension type in dimension subclass constructors.

* Add DRW_Entity::setWidthMm.

In principle there's an algebraic relationship between the DXF line
width value and line thickness in millimeters, and everything except
AutoCAD accepts any value from the range, but AutoCAD ignores all
values except a few chosen ones.

* Don't use pure virtual functions in DRW_Interface.

This forced API consumers to implement a lot of useless empty
functions for no good reason.

* Fix H/V align reading for MTEXT.

* Remove unused DRW_Interface::setBlock.

* Silence -Wunused-parameter warnings.

These are all in our default implementation of DRW_Interface, which
ignores everything it receives, so it's OK.

* Add DRW_Dimension::{has,get,set}ActualMeasurement.

* Don't add spline control points twice.

This caused a double free when deallocating DRW_Hatch.

* Remove dwgR::testReader().

* Implement variants of read/write functions that take std::[io]stream*.

* Remove the fileName field from dwgR/dxfRW.

It's more trouble than it's worth when supporting Windows. Instead,
require the caller to always use the appropriate overload of
std::[io]fstream constructor (possibly the wchar_t* one).

* In POLYLINE, use vertex type that matches the polyline type.

This makes polylines readable in AutoCAD again.

* Fix type conversion warnings.

* Fix GCC warning -Wmisleading-indentation.

* Added more codes for colors supported by DXF.

* Add support for $TDCREATE.

According to documentation $TDCREATE has code 40 and contains "Local date/time of drawing creation (see “Special Handling of Date/Time Variables”)".

* Fix opening files saved as DXF R10 in AutoCAD.

When saving in the AC1006 format, several DIMSTYLE groups were
erroneously omitted.

* Up to DXF R12, the default layer "0" may be left undefined.

Some standards mandate the default layer to be unused.

* Use DRW_Block::layer when writing blocks.

Before, the layer was hardcoded to "0" in the writer.

* Misc typos: length

Found via codespell and grep

* Misc. source typos: compressed

Found via `codespell`

* Misc. typos

* DRW_Coord: Simplify constructor/assignment.

Having a user-specified assignment operator but default copy-constructor
violates rule of 2/3/5/0.

Found by clazy.

* Add const-qualifiers to DRW_Dimension getters

getExtrusion and getName was missing const qualifiers.

* Read extrusion tags for dimension entities

Dimension entities support DXF codes 210, 220, 230 and and DRW_Dimension
already had a extPoint member, but the tags were never used when
parsing.

---------

Co-authored-by: whitequark <[email protected]>
Co-authored-by: EvilSpirit <[email protected]>
Co-authored-by: Roman Telezhynskyi <[email protected]>
Co-authored-by: luz.paz <[email protected]>
Co-authored-by: Johannes Rehnman <[email protected]>
mlight-lee pushed a commit to mlight-lee/libdxfrw that referenced this issue Feb 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants