QCAD - 2D CAD System.

Click here for a documentation of the DokuWiki formatting syntax that can be used in reports

Please search for existing tasks (also closed ones) before opening a new task.

Please make sure that you are using the latest Version of QCAD before posting a bug (menu Help > Check for Updates)


FS#892 - DXF compatibility issues when saved as DXF R15 / dxflib

Attached to Project: QCAD
Opened by Tamas TEVESZ (kazmer) - Sunday, 18 August 2013, 02:55 GMT+2
Last edited by Andrew (andrew) - Wednesday, 16 October 2013, 20:02 GMT+2
Task Type Bug Report
Category QCAD (main)
Status Closed
Assigned To Andrew (andrew)
Operating System All
Severity Low
Priority Normal
Reported Version 3.2.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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 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).

This task depends upon

Closed by  Andrew (andrew)
Wednesday, 16 October 2013, 20:02 GMT+2
Reason for closing:  Fixed
Comment by Tamas TEVESZ (kazmer) - Sunday, 18 August 2013, 02:59 GMT+2

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).

Comment by Tamas TEVESZ (kazmer) - Sunday, 18 August 2013, 03:12 GMT+2

The online viewer at gallery proficad eu /tools/autocad-viewer.aspx says "we could not open this drawing" for the original one, and renders the one recovered by DraftSight OK.

Same goes for www dwgconverter org

The Java viewer at www escape de /~quincunx/dxfviewer/ says the following for the original drawing:

3:05:26 AM      Reading HEADER...
3:05:26 AM         $ACADVER=AC1015
3:05:26 AM         Version AC1015 (AutoCAD 2000/2000i/2002)
3:05:26 AM      Unexpected HEADER entry SECTION in line 72!

and renders the DS-recovered version OK.

(URLs mangled as the forum wouldn't allow them otherwise, but I feel in this case they are proper part of the report.)

Comment by Andrew (andrew) - Sunday, 18 August 2013, 12:12 GMT+2

Some notes:

QCAD 3.2 saves as DXF 2013 by default (the latest DXF format). Draftsight and other products may not support that version of DXF. Try an older DXF format version instead (e.g. 2000).

Backwards compatibility with QCAD 2.0 is no longer an objective. QCAD 3.2 is available as free community edition as well (GPLv3) and should be used instead.

Comment by Tamas TEVESZ (kazmer) - Sunday, 18 August 2013, 23:28 GMT+2

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
Comment by Andrew (andrew) - Monday, 19 August 2013, 00:19 GMT+2

Thanks for the details. You are using QCAD 3.2 without the Teigha plugin for DXF / DWG support. I've adjusted the report accordingly.

Comment by Tamas TEVESZ (kazmer) - Wednesday, 28 August 2013, 15:08 GMT+2

One more note: I tried to just open and save dimensions.dxf with QCAD (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.

$ grep -A2 ACADVER dimensions.dxf dimensions-teigha.dxf 
dimensions.dxf-  1
dimensions-teigha.dxf-  1


  • Autodesk DWG TrueView 2014 opens and renders it fine
  • So does DraftSight V1R3.2
  • So does QCAD2

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

Rallaz commented:

dxf files created with dxflib (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.

Comment by Tamas TEVESZ (kazmer) - Monday, 02 September 2013, 11:35 GMT+2

I saw a comment in 0cf489e9 that this was fixed, so I re-tested, with the original dimensions.dxf loaded and just saved again in 0cf489e9 (dimensions2.dxf, attached).

The diff is as follows:

--- dimensions.dxf      2013-09-02 11:16:09.011157218 +0200
+++ dimensions2.dxf     2013-09-02 11:16:46.075823675 +0200
@@ -1,5 +1,5 @@
@@ -69,6 +69,8 @@
+  0

and some textstylex to textstyley changes.
Test results:

  • the proficad eu online viewer still "we could not open this drawing".
  • the escape de viewer says the following (different than before):
10:39:58 AM     Reading HEADER...
10:39:58 AM        $ACADVER=AC1015
10:39:58 AM        Version AC1015 (AutoCAD 2000/2000i/2002)
10:39:58 AM     Reading TABLES...
10:39:58 AM     Reading BLOCKS...
10:39:58 AM     Skipping unknown ENTITIES SECTION!
10:39:58 AM     Encountered 5 unresolvable references!
10:39:58 AM     de.caff.dxf.file.DxfDICTIONARY cannot be cast to de.caff.dxf.file.a
  • DraftSight: "Drawing file requires recovery".
  • ARES Commander Edition 2013 (which is basically the same engine as DraftSight, just presumably a slightly newer version): same as DraftSight
  • Autodesk DWG TrueView 2014 (also different from what it was before, maybe more informative now):
Skipping duplicate definition of CONTINUOUS in LTYPE Table
Error in STYLE Table
Premature end of object on line 1028.
Invalid or incomplete DXF input -- drawing discarded.
  • QCAD2 still opens it, with dimension lines still skewed as in first post.

Thanks for your efforts in repairing this!

Comment by Tamas TEVESZ (kazmer) - Sunday, 13 October 2013, 21:14 GMT+2

With a recent update of dxflib to, 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!

Comment by Tamas TEVESZ (kazmer) - Monday, 14 October 2013, 10:34 GMT+2

Git rev e4f46f.

  • Autodesk DWG TrueView 2014:
The following error was encountered while reading
in TEXT starting at line 1692:
Unexpected DXF group code: 73
Invalid or incomplete DXF input -- drawing discarded.
  • DraftSight V1R3.2, V1R4.0, ARES: apparently OK, dim4-draftsightv1r32.png
  • QCAD (Teigha): apparently OK
  • QCAD2: Skewed dimension lines (I know, I know, just saying :)
  • proficad.eu viewer: apparently OK
  • 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)

Looking better with each iteration. Thank you.

Comment by Andrew (andrew) - Monday, 14 October 2013, 13:24 GMT+2

Thanks Tamas.

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.

Comment by Tamas TEVESZ (kazmer) - Monday, 14 October 2013, 16:19 GMT+2

This is very plausible, after a single XP, the caff.de viewer displays it OK.

Thanks for your effort and the fix!

Comment by Andrew (andrew) - Monday, 14 October 2013, 18:25 GMT+2

The 'Unexpected DXF group code: 73' should be fixed in the latest commit:

Comment by Tamas TEVESZ (kazmer) - Wednesday, 16 October 2013, 16:24 GMT+2

Sadly, it isn't yet :(

--- dimensions4.dxf     2013-10-14 10:02:21.676290848 +0200
+++ dimensions5.dxf     2013-10-16 13:49:52.774248574 +0200
@@ -61,6 +61,10 @@
+  3
+  9
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.

The essence is the following diff for each of the six TEXT entities:

--- dimensions5.dxf     2013-10-16 13:49:52.774248574 +0200
+++ dimensions6.dxf     2013-10-16 16:05:24.422286280 +0200
@@ -1734,6 +1734,8 @@

This may be a completely false direction, but may also give you an idea as to where to look.

Continued thanks for your efforts!

Comment by Andrew (andrew) - Wednesday, 16 October 2013, 16:57 GMT+2

Is that with QCAD 3.3.4?
The two lines 100 and AcDbText is exactly what has changed from 3.3.3 to 3.3.4.

Comment by Tamas TEVESZ (kazmer) - Wednesday, 16 October 2013, 19:49 GMT+2

Hm. There's something weird going on.

After a full clean checkout and rebuild, it does.

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).


Comment by Andrew (andrew) - Wednesday, 16 October 2013, 20:02 GMT+2

OK, great, thanks!