Export DXF : closed path not working

First screenshot.

Second screenshot.

DXF v2010 from AutoCAD 2013.

DWG v2010 from AutoCAD 2013.

I have not been able to detect any qualitative difference between the dxf file produced by Inkscape 0.48.3.1 (Desktop Cutting Plotter) and the dxf file file attached above which was produced by AutoCAD.

In both cases the dxf file contains two LWPOLYLINE entities. Attribute 90 = 7 and 8, as expected. Attribute 70 = 0 in all cases, which means the LWPOLYLINE is open, not closed.

Could you attach an AutoCAD dxf file that has the characteristics you are looking for?

This is a Bricscad v12 DXF, with some additional explanations.

thanks, this has the information I was looking for, it has attribute 70 = 1 as expected.
I'll take a look at it this weekend to see what can be done.

attached is a modified version of dxf_outlines.py. This will set the closed flag, attribute 70, if the polyline is closed in the svg file.

in order to use this, copy it into the directory \Inkscape\share\extensions\ to replace the file that is currently there.

I tested the new extension : the polyline is now closed, but there is still a superfluous node.
SVG file here, with a DXF file result from Inkscape new extension, and a second DXF file revised with the good result (I think...).

This is Inkscape export, with a 7 nodes polyline , while the SVG file contains a polyline with 6.

And now the DXF file (modified by me) with a closed 6 nodes polyline, which is, in my opinion, the most correct result.

Thanks you for your attention.

I agree that the last path is mathematically redundant. However, this is a behaviour that is common to all the Python-based extensions that do path manipulation in Inkscape, so it is not feasible to modify this behaviour. (And, of course, it does not do any harm to have a redundant node present.)
    In the original svg notation, the last path is repesented by a 'z' or a 'Z'. When this is converted into a path notation that is useable by the Python extensions, it gets converted into what is called a cubicsuperpath notation using a Python file with the name cubicsuperpath.py, where the cubic refers to cubic Bezier curves, and the superpath refers to the fact that it can represent either Bezier curves or straight lines, and that they can be either disjoint or contiguous, and also either smooth or cusp. In this superpath notation the term 'z' or 'Z' does not exist, and so it is replaced by writing the last node explicitly. In any event, this notation is fundamental to the operation of the Python extensions, so it is not feasible to modify it.

Ok, thank you for your explanation :)

good to hear.
committed to bzr rev 12033

To conclude, and get polylines without redundant points, I found two ways to clean it all, with Covadis :
_ the POLYSUPPDOUB command

... or
_ the MODPOLY command (+ supprimer Doublon)

This is quite efficient when there are several tens (or even hundreds) of polylines to clean.

good to hear, thanks for investigating this!

Diff to backport to lp:inkscape/0.48.x

Fix backported to lp:inkscape/0.48.x in revision 10001.

improved fix committed to rev 13980, for Bug 1429184.
 this fixes an incorrect implementation of a closed flag on LWPOLYLINE. The LWPOLYLINE output will now not contain a redundant segment closing the object. This can be used by downloading dxf_outlines.py and dxf_outllines.inx from:
 http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head:/share/extensions/

just a word of warning, though, the new version uses a standard Inkscape resolution of 96dpi, not 90dpi.