Details

This report concerns QCAD 3.2.1 when used without the Teigha plugin for DXF / DWG support:

While playing around, I created a simple drawing with QCAD 3.2.0 with just some lines and dimensions.

QCAD 3.2.0 renders it as shown in dim-qcad320.png.

QCAD 2.0.5.0-community renders it as shown in dim-qcad2050free.png.

DraftSight V1R3.2 pops up a window upon loading that says “Drawing file requires recovery. Do you want to proceed?”. If I choose recovery, it renders it as shown in dim-draftsightv1r32.png (if I choose not to recover, it quits). If now I save the recovered drawing in “R2000-2002 ASCII drawing (*.dxf)” format (which looks closest to what QCAD 3.2 offers to save as by default), both QCAD 2 and QCAD 3.2 render this repaired drawing as intended (ie. as in dim-qcad320.png).

The font difference in the DraftSight image is apparently due to a missing font on DraftSight's side and doesn't as such appear to be a part of the problem (the aligned dimension lines being somehow skewed).

As for QCAD 3.2 (actually, Git 6171094d2), I don't seem to be able to choose a format to save as (the "Format" field has only one item, "R15 (2000/LT2000) DXF Drawing (dxflib) (*.dxf)", either with a new empty drawing or "Saving as" an existing drawing).

DraftSight (according to its "File type" drop-down of the "Save as" dialog) does support DXF 2013 ("R2013 ASCII Drawing (*.dxf)", though the Wikipedia article has a remark to the effect of

DraftSight allows users to access DWG/DXF files, regardless of which
CAD software was originally used to create them, except AutoCAD 2013
and later.

I readily admit "DXF 2013" and "R2013 ASCII Drawing" could mean different things, for all I know.

I have tried the procedure outlined in "Creating a Simplified DXF File" chapter of the QCAD book, with results as follows:

Just after one XP, DraftSight is able to open the drawing and render it as intended

So is QCAD2 (I understand the no backwards compatibility objective, just including it for completeness)

The escape.de one can't render it even after three XP iterations, though I have found a remark in its docs stating "AutoDesk introduced incompatible and deliberatly obscured features in DXF with R13 so don't expect support for newer versions too soon – if ever."

The proficad.eu one can't open one and two XP iterations, the resulting DXF is too large for it after three.

I have also tried Autodesk's DWG TrueView 2014 (download autodesk com /esd/dwgtrueview/2014/SetupDWGTrueView2014_ENU_32bit.sfx.exe) Product version: I.18.0.0 with the following results:

For any drawing created with QCAD 3.2 (regardless of explosion and whatnot), it says "Error 372 in drawing header on line 72. Invalid or incomplete DXF input – drawing discarded." (e. g. dimensions.dxf in the first post; line number varies with other drawings)

For the one repaired by DraftSight, it is opened and rendered fine

For a random simple drawing created with QCAD 2, it is opened and rendered fine

One more note: I tried to just open and save dimensions.dxf with QCAD 3.2.2.0 (binary), where "save" means "Save as R15 (2000/LT2000) DXF Drawing (Teigha)" – basically just using a different engine (Teigha vs. dxflib) to write the same format data.

There is a comment on the LibreCAD (github LibreCAD issue #404) forums stating:

Rallaz commented:
dxf files created with dxflib 3.1.5.0 (QCAD 3.2) are bad.
To correct open it with some program that uses dxflib 2.xx and save it.
The bug are:
dxflib 3.xx do not add mandatory ENDSEC code.

I can't personally comment on the correctness (or the opposite thereof) of this statement, but it might help.

With a recent update of dxflib to 3.3.4.0, things are getting a little bit better. dimensions3.dxf is attached, results areas follows:

Autodesk DWG TrueView 2014:

Skipping duplicate definition of CONTINUOUS in LTYPE Table
The following error was encountered while reading
in TEXT starting at line 1660:
Unexpected DXF group code: 73
Invalid or incomplete DXF input -- drawing discarded.

DraftSight V1R3.2: Drawing opens, but the dimensions lines are completely missing, see dim3-draftsightv1r32.png

DraftSight V1R4.0: Same as above, see dim3-draftsightv1r40.png

ARES Commander Edition 2013: Same as DraftSight

QCAD2: Same skewed dimensions lines as before, see dim3-qcad2050free.png

QCAD 3.3.3 (the binary off the download page, using Teigha): dimension lines are completely missing (basically the same as DS and ARES), see dim3-qcad333.png

One more thing appeared as well. Opening the original dimensions.dxf and saving it with Git revision 15493d, one of the diff hunks looks as follows:

-Line at an angle of 45<B0>
+Line at an angle of 45\U+00b0

This QCAD opens the original dimensions.dxf fine, renders it fine, saves it fine, but when the now-saved dimensions3.dxf is opened again, the label on one dimension line becomes "Line at an angle of 45\U+00b0", see dim3-qcadr15493d.png (it is supposed to be a "degree" sign, U+00b0).

Let me know if you need any more information, and again, thanks for your continued efforts in hunting this one down!

dwgconverter.org: so completely bonkers junk I'd chalk this up to them.

escape.de (now caff.de; caff de /dxfviewer/dxfviewer-swing.jar) viewer: opens without trouble, but the dimension lines are missing, see dim4-caff22004.png (it's not just that the lines are too thin to render on the bitmap; I have zoomed in considerably, still nothing)

I have no explanation for the TrueView error at the moment, but will look into it once time permits.

Viewers which are not showing dimension entities are likely not able to render dimension entities. They expect an unnamed block to be present which contains the visualization of the dimension (lines, solids, text, etc). This is not within the scope of dxflib and will likely not be implemented anytime soon.

The following error was encountered while reading
in TEXT starting at line 1696:
Unexpected DXF group code: 73
Invalid or incomplete DXF input -- drawing discarded.

I dug around a bit, made some educated guesses after reading most of the Internet (:)), especially forums autodesk com /t5/AutoCAD-2000-2000i-2002-DWG/error-opening-DXF-with-SHX-attachment/td-p/225457, and I eventually came up with a file that is actually read by TrueView as well as the other things mentioned before (including Teigha), and it also seems to render OK in each of them (trueview.jpg, other screenshots not taken now), see dimensions6.dxf.

But, adding 100 AcDbText and adding $DWGCODEPAGE ANSI_1252 were added at the same commit, yet for a partial rebuild after checking that out yielded only the $DWGCODEPAGE bit added to the dxf. Though one hunk of that commit is core, the other is 3rdparty... Weird.

OK, for the original issue, as far as I can tell, it can be closed, as things seem to be in order now. Thank you for your persistence in fixing it!

I'll open a different bug for the build issue (I see now how it goes wrong, I just don't yet see why).