Export DXF : closed path not working

Bug #1098283 reported by Hans-Karl on 2013-01-10
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Low
Alvin Penner

Bug Description

Found it in Inkscape R12010.

When I export to DXF a closed path with n nodes, I get an unclosed path with n+1 summits in AutoCAD (or AutoCAD-like).

This is a disturbing detail because when I apply a round effect on this in AutoCAD, the form becomes different.

I join a SVG file, 2 screenshots and the DXF + DWG results.

Hans-Karl (jchbraun) wrote :
Hans-Karl (jchbraun) wrote :

First screenshot.

Hans-Karl (jchbraun) wrote :

Second screenshot.

Hans-Karl (jchbraun) wrote :

DXF v2010 from AutoCAD 2013.

Hans-Karl (jchbraun) wrote :

DWG v2010 from AutoCAD 2013.

Alvin Penner (apenner) wrote :

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?

su_v (suv-lp) on 2013-01-11
tags: added: dxf exporting
Hans-Karl (jchbraun) wrote :

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

Alvin Penner (apenner) wrote :

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.

Alvin Penner (apenner) wrote :

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.

Changed in inkscape:
status: New → Confirmed
Hans-Karl (jchbraun) wrote :

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

Hans-Karl (jchbraun) wrote :

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

Hans-Karl (jchbraun) wrote :

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.

Alvin Penner (apenner) wrote :

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.

Hans-Karl (jchbraun) wrote :

Ok, thank you for your explanation :)

Alvin Penner (apenner) wrote :

good to hear.
committed to bzr rev 12033

Changed in inkscape:
status: Confirmed → Fix Committed
su_v (suv-lp) on 2013-01-17
Changed in inkscape:
assignee: nobody → Alvin Penner (apenner)
importance: Undecided → Low
milestone: none → 0.49
tags: added: backport-proposed
Hans-Karl (jchbraun) wrote :

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

Hans-Karl (jchbraun) wrote :

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

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

Alvin Penner (apenner) wrote :

good to hear, thanks for investigating this!

su_v (suv-lp) wrote :

Diff to backport to lp:inkscape/0.48.x

su_v (suv-lp) wrote :

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

Changed in inkscape:
milestone: 0.49 → 0.48.5
tags: removed: backport-proposed
Changed in inkscape:
status: Fix Committed → Fix Released
Alvin Penner (apenner) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers