Importing or opening a DXF file leaves some lines out.

[Brandon Wellborn]

When I open or import a DXF drawing into Inkscape, some of the lines do not show up. Using a CAD program, I've created some drawings and have exported the drawings to DXF. There were several options for exporting to DXF (AutoCAD 14, AutoCAD 2000, AutoCAD 2004, or AutoCAD 2007). None of the options will import correctly into Inkscape. Some of the lines show up and some do not. I don't understand.

I've tried the same files using CorelDraw x3 and x4 with success. Thanks for any help.

[Brandon Wellborn (bwellbor)]

There is a curved line missing from this imported DXF file when imported into Inskape. The format is AutoCAD 2000.

[Brandon Wellborn (bwellbor)]

This is the actual DXF file.

[su_v (suv-lp)]

No longer reproduced with upcoming Inkscape 0.48.1 (tested with r9737 from the 0.48.x branch)

(imported with scale factor 10.0)

[su_v (suv-lp)]

@Alvin - can you confirm that current trunk (as well as backported changes to the 0.48.x branch) handle the data in the DXF file as expected?

[su_v (suv-lp)]

Sorry - made a mistake and overlooked the missing paths…

Reproduced with Inkscape 0.48.0 and 0.48+devel r9938 on OS X 10.5.8

[Alvin Penner (apenner)]

    the curve that is missing is a spline of a type that is not recognized by the import routine. The routine will recognize cubic Beziers, defined by 4 points, and quadratic Beziers, defined by 3 points. Unfortunately this spline is defined by 5 points and so it cannot be represented as a single Bezier as far as I can tell.
    However, I will look at it some more over the next little while, to see if it can be represented properly as two quadratic Beziers.

[Alvin Penner (apenner)]

    attached is a new version of dxf_input.py, which will draw the missing shape by representing it as two quadratic Beziers. The resulting shape is not precisely the same as the shape drawn by Voloview, which appears to be a perfect circle. However, it is noticeably better than the shape drawn by QCad 2.1.3.2, which is much too rectangular.
    I suspect that the difference in rendering is caused by the dxf Group Code 41, which is called Weight in the dxf documentation, and is not being used here. However, I do not know how to implement this particular group code within the context of a Bezier curve.
    I have also added the attributes width and height to the main svg tag, so that the page size will be A4. This was a partial response to comment 2 in Bug 657284.

[tatankam (tatankam)]

I have some missing line when I import a DXF using this last dxf_input.py too

[tatankam (tatankam)]

I attach to you the dxf with missing lines whan I open with Inkscape.

If I open it with eDrawings SolidWorks, it is open correctly.

Thanks!

[Alvin Penner (apenner)]

    confirmed, the file errorink.dxf contains some spline types that are not supported by the dxf import routine. These are cubic splines, not quadratic, so they are different than the problem originally reported here. They also contain more than 4 control points, so it will not be possible to represent them as a single Bezier spline.
    I do not know if it will be possible to represent these as some combination of Bezier splines, will need to think about that for a while...

[Alvin Penner (apenner)]

attached is a modified version of the file dxf_input.py. This will read in a cubic NURB of arbitrary length and will convert it into a sequence of Bezier curves using knot insertion. With this change the file errorink.dxf is rendered properly, as far as I can tell.

In order to test this, you will need to copy dxf_input.py into the directory C:\Program Files\Inkscape\share\extensions\ to replace the file that is currently there.

as usual, any testing would be appreciated.

[tatankam (tatankam)]

Great Alvin!
This version solved the missing lines!

Now I have another problem.
When I import from Inkscape, it seems that the gray lines are larger than the original.
Furthermore, the quotes are strange : the dxf import added a decimal (es. 49 become 49.0 ) even if there wasn't in the original, and the arrows are missing, and some orizanthal and vertical quote are missing.

In the attachment you see.
1) original.dxf : the dxf to import
2) screenshot.jpg : screenshot of the original.dxf opened with eDrawings Solidworks
3) original.swf : generated from the original.dxf

Could you help me ?
Thanks for your help.

Mario

[su_v (suv-lp)]

@tatankam - please file separate reports for your new issues/feature requests which are not related to this report about missing support for certain types of curves (splines):

a) "it seems that the gray lines are larger than the original."
I'm not sure what this refers to: is the geometry of some paths differently scaled or is it about the stroke width (which can be edited in Inkscape)?

b) Dimensioning support: How detailed could or should Inkscape support specific dimensioning options from the CAD application producing the DXF file (e.g. precision settings for individual dimension values, types of symbols used for the dimensioning lines) at all depends on someone willing to investigate, compare and implement it for Inkscape, I guess …

[tatankam (tatankam)]

a) you are right : if I edit the "Stroke width" to 40% in inkscape, I obtain a better result, so I can not consider it a bug.

b) I open a new bug problem for this.
Thanks!

[Alvin Penner (apenner)]

thanks for testing, committed to bzr rev 10183

will check out the scaling issue separately, sometime...

[su_v (suv-lp)]

@Alvin - are r9965 and r10183 save to backport to the 0.48.x branch? Or do they depend on other changes only in trunk (e.g. to inkex.py or other shared modules)?
(r10131 for bug #739803 also proposed for backport)

Change log for trunk:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes?filter_file_id=dxf_input.py-20091128124040-aej0x7yhxng1m6ly-12068>
Changelog for 048.x:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH/changes?filter_file_id=dxf_input.py-20091128124040-aej0x7yhxng1m6ly-12068>

[Alvin Penner (apenner)]

yes, I believe it should be safe to backport these changes, they do not introduce any new dependencies on other files. I would suggest the most recent one, rev 10192, which modified both dxf_input.py and dxf_input.inx

[su_v (suv-lp)]

Alvin Penner wrote
> I would suggest the most recent one, rev 10192,
> which modified both dxf_input.py and dxf_input.inx

I didn't recommend r10192 for backporting because it introduces new strings in the dialog which would require to update the translation files.
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10192>

[Alvin Penner (apenner)]

yes, I forgot about that...

okay, how about rev 10183. This has a fix in it for Bug 739803 which is actually better than the original fix in rev 10131

[su_v (suv-lp)]

Alvin Penner wrote
> okay, how about rev 10183.

Yes (as asked earlier: "are are r9965 and r10183 save to backport to the 0.48.x branch?"). To summarize for DXF input:

Proposed revisions for backporting (tag 'backport-proposed'):
bug #739803: r10131
bug #685707: r9965, r10183
bug #656899: r9824

No packport of r9629, r9642 and r10192 due to string changes.

Changelog:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes?filter_file_id=dxf_input.py-20091128124040-aej0x7yhxng1m6ly-12068>

[jazzynico (jazzynico)]

Backported in the branch, revision 9811.