DXF import/export empty

[M8R-98booy]

I open Inkscape 0.48 on Win 7 x64 and draw a black rectangle, then Save As Desktop Cutting Plotter (R13) .dxf, and then re-import that that file again. The resulting drawing is empty!

I tried to open the dxf-file with other cad programs and they also show an empty file.
If I create a new dxf-file with another cad program, Inkskape shows only an empty drawing.

It seems that both, the export and import filters in 0.48 are broken.

[su_v (suv-lp)]

a) export with a black rectangle empty:
You need to convert rectangles to paths before exporting to DXF else they do not get exported.
Reproduced with Inkscape 0.48 and 0.48+devel r9817 on OS X 10.5.8.

b) import of externally created DXF files empty:
Can you attach a DXF file created by another CAD application that doesn't import into Inkscape?

[M8R-98booy (m8r-98booy)]

a) If this is the desired behaviour, then at least a warning message should be displayed.
b) I attached a file DsgCAD.dxf that shows up empty in Inkscape. Illustrator can open it correctly. (Two intersection Rectangles.)

[M8R-98booy (m8r-98booy)]

I also have another file DblCAD.dxf that shows up incorrecly, i.e. distorted.
expected: two intersecting rectangles.
Inkscape shows: one rectangle without a line at the left side, and one rectangle where the last node has moved into the center.

Illustrator shows both my files correctly.

[su_v (suv-lp)]

a) missing rectangles
>> convert rectangles to paths before exporting
> If this is the desired behaviour, then at least a warning
> message should be displayed.

It's not expected behavior (afaiu) - but a workaround that allows to use the current DXF export without omitting the rectangles.

b) attached files:
> DsgCAD.dxf

Reproduced with Inkscape 0.48 and 0.48+devel r9819 on OS X 10.5.8: the drawing is empty besides two empty layer groups (0, 1), a marker and a pattern definition.

> DblCAD.dxf

Reproduced with Inkscape 0.48 and 0.48+devel r9819 on OS X 10.5.8: left edge of the upper rectangle is missing, the last node (lower left corner) of the lower rectangle is displaced to the upper region inside the rectangle.

QCad 2.0.5.0 (Communitiy Edition) seems to import and display both DXF files correctly.

[Alvin Penner (apenner)]

yes, the drawing DsgCAD.dxf is drawn using the entities POLYLINE and VERTEX, which are not supported in this input routine. The workaround is to load it into QCad and then immediately save it under a new name, attached:

[Alvin Penner (apenner)]

in QCad the default entity in this case is LWPOLYLINE, which is supported by the Inkscape routine. When I load this into Inkscape with no scaling, I get the attached, which appears to contain the original image.

The problem is that there is a very high level of redundancy in the various entities that AutoCAD uses, such as LINE, POLYLINE, and LWPOLYLINE, and so a decision was made to support only those elements that are 'most likely' to be used by QCad.

[Alvin Penner (apenner)]

with respect to DblCAD.dxf, this one "should have" worked because it uses the entity LWPOLYLINE, which is supported. I will investigate this to see if I can find the problem

As before, there is a workaround, load it into QCad and immediately re-save it to produce:

[Alvin Penner (apenner)]

then load this into Inkscape to produce the attached, which appears to be okay.

[su_v (suv-lp)]

1) Workaround confirmed for both DXF files using QCad to resave as DXF. Should we close this report or keep it open as wishlist item to add import support for additional AutoCAD entities?

2) <rect> unsupported:
@Alvin - I guess DXF export fails to support the rectangle shapes because Inkscape doesn't add the (redundant) 'd' path attribute like it does for the other parameterized shapes - it is not needed because Inkscape uses the basic SVG shape for rectangles [1]. Should this be filed as separate (wishlist) report or would it be difficult to implement?

Inkscape rectangle:

    <rect
       style="fill:#ff8080;fill-opacity:0.85098039;stroke:#000000;stroke-width:2;stroke-opacity:1"
       id="rect15890"
       width="130"
       height="90"
       x="20"
       y="20" />

Example from the SVG spec:

  <rect x="400" y="100" width="400" height="200"
        fill="yellow" stroke="navy" stroke-width="10" />

[1] <http://www.w3.org/TR/SVG11/shapes.html#RectElement>

[Alvin Penner (apenner)]

Hi,
      three part answer, not entirely sure if this answers the question or not:

1. with respect to the lack of support for POLYLINE and VERTEX on import, I don't think this is worth doing. These elements are typical of AutoCAD release 12, which is obsolete. LWPOLYLINE is typical of release 13, which we are attempting to support.

2. with respect to the bad rendering of LWPOLYLINE, I will try to look at this within the next week, and perhaps this report could be kept open for that purpose, assuming this can be fixed.

3. with respect to rectangles on export, I think this would probably be straightforward to do. Perhaps this report or some other report could be kept open for that purpose, although the time scale would be more like 3 months instead of one week.

[su_v (suv-lp)]

@Alvin - yes, it answers all my questions (sorry for jumping in impatiently while you were in the middle of investigating both DXF files ;-) )

Let's keep this report about the issue of importing DXF and the remaining issue with the second test file 'DblCAD.dxf'. I will file the request to support SVG <rect> separately so that the issues can be tracked (and fixed/closed) independently.

[su_v (suv-lp)]

New feature request added for DXF import:

Bug #657289 “[dxf import] add support for basic SVG shapes like <rect>”:
<https://bugs.launchpad.net/inkscape/+bug/657289>

[su_v (suv-lp)]

oops - sorry for the confusion in the bug summary:

New feature request added for DXF export:

Bug #657289 “[dxf export] add support for basic SVG shapes like <rect>”
<https://bugs.launchpad.net/inkscape/+bug/657289>

[Alvin Penner (apenner)]

attached is a modified version of the file dxf_input.py.
With this change, the file DblCAD.dxf should load properly without the need for QCad as an intermediate step.

[su_v (suv-lp)]

Fix confirmed for 'DblCAD.dxf' with Inkscape 0.48 and 0.48+devel r9823 on OS X 10.5.8 and modified version of 'dxf_input.py' from comment #14.

[M8R-98booy (m8r-98booy)]

Great! The new dxf_input.py for DblCAD.dxf Works for me. Thanks!

[Alvin Penner (apenner)]

- good to hear, committed to bzr rev 9824
- I'll mark this as Fix Committed on the assumption that the remaining issues can be dealt with in Bug 657284 and Bug 657289
- if you feel that there are still unresolved issues besides these, feel free to reopen the report.

[jazzynico (jazzynico)]

@Alvin - I'm currently trying to patch the branch so that the backport-proposed taged reports apply to 0.48.2, but it's a bit difficult to do that due to two commits revision 9629 and 9642. They modify the code of the python and INX files and add two new options: Text Font, and Gcodetools compatible point import.
Do you think it would work if we apply the changes made in the Python file, but hide the new options in the INX one? The idea here is to keep the parameters defined in the INX file but hide the option in the dialog and use the default value of the hidden options.
And if it works for these two commits, would it also work if we use the very last trunk python file and hide all the new strings in the INX file?

[Alvin Penner (apenner)]

yes, I believe this should work. I just did an experiment where I used the file dxf_input.inx from rev 8563 which was the last rev before 9629. And I used it together with the python file dxf_input.py from rev 10192, the latest version. I could not detect any problems using this combination. There are a number of new parameters that have been defined in the inx file since then , but in each case there is a default value defined in the Python file so it will still run properly using the old inx file. The reverse situation, with a newer inx file, will cause a crash.

[jazzynico (jazzynico)]

Just tested the latest trunk version of dxf_input.py in the 0.48.x branch on Windows XP, and apparently it works with no issue.
Tests on Ubuntu planned later today.

[jazzynico (jazzynico)]

Backported in the branch, revision 9811.