Desktop Cutting Plotter (*.dxf) output generates unreadable SPLINE

    A proposed modification is attached. The file dxf_outlines.py has been modified as follows : the file dxf_outlines.dxf has been added as a new dependency and has been used as a template file to generate a header and footer that are consistent with AutoCAD 2000.

   The modification was tested by converting the file dxf_test.svg to dxf format. The resulting output file was readable by Voloview Express 2.01 and DWG TrueView (Build R17.1.65)

Note : before doing the output, two slight massages were done on the svg file :

1. text was converted using the Path | Object to Path procedure.

2. all objects on the drawing were selected using Edit | Select All, and were slightly translated and then translated back again, which removed all the 'transform' attributes from the svg paths.

    just for fun, attached is a DXF version of the Inkscape logo.

Before doing the output, the menu procedure Object | Ungroup was used to get rid of an unwanted 'transform' attribute.

Alvin--thanks so much for submitting a patch for this! Improved DXF support is a very frequently-requested feature.

I'm re-attaching your changes as a patch (in future you can generate these yourself using svn diff, see http://wiki.inkscape.org/wiki/index.php/WorkingWithSVN#Generating_a_Diff ). Sending in patches this way will improve the likelihood of them getting applied to the source tree, since the developers can easily see exactly what changes you've made.

I can confirm that Inkscape can save a simple file using this extension which I can then open in qcad... Nice!

Aaron--could you check out Alvin's patches? See also bug 167768 Thanks!

It is true that some dxf readers do not support SPLINEs but it is a valid directive. Could you explain what is incorrect about the DXF headers as they stand? They are minimalist by design.

   First of all before I get too far, two apologies, I apologize for the length of this response because it will be long, and I apologize for mangling your code, because it was elegant. The code you wrote for python extensions is some of the most elegant and powerful stuff I have ever seen. I'm an old QBASIC person, grew up on FORTRAN IV, so this is a bit new to me, and very refreshing after looking at spaghetti code at work.
  So, to get to the point, I believe the syntax you are using for SPLINE probably originated in AutoCAD Release 13. Any references that I have seen before R13 typically contained multiply segmented lines or polylines even if they used the word "spline". To me the word spline means one thing only, namely cubic Bezier, anything less than that is not a spline. The problem, I think, is that in order to get AutoCAD to recognize the spline you need to specify a rev number. In this case the rev number is anything greater than AC1012, which is code for Release 13. So you need to say
  9
$ACADVER
  1
AC1012 (or greater)
in the HEADER section. Then the spline elements will be properly recognized.

  Unfortunately, that's the good news. The bad news is that you will now have to specify unique handles for the various ENTITIES. afaik handles became optional in Release 10 and became mandatory in Release 13. This means that you need to have the code
  9
$HANDSEED
  5
xxx
in the HEADER, and you also need to specify unique handles for every ENTITY using the syntax
  5
xxx
for every ENTITY. (btw the code that I used for handles was actually ripped off from pstoedit, which I believe is fully compatible with the syntax of the spline that you used.)

    Anyways, that was also the good news, the really bad news is that I have not been able to find any meaningful documentation on what would constitute a reasonable value for $HANDSEED, that appears to be a very closely guarded secret.

    This is the point at which I gave up and cried uncle. I could not make sense out of where this data is coming from, so I generated a standard ACAD2000 format DXF file using AutoCAD LT 2002, and used it as a template.

   I believe that if a meaningful value of $HANDSEED could be developed, then a more minimalist version could be produced, which I am all in favor of, but can't figure out how to accomplish.

   Thanks for the feedback, I will investigate the handle issue some more, and if I have no luck at all then I'll report back.

-APP

Thank you for the thorough explanation.

There have been numerous calls for improvements to the DXF output. I think what people are looking for is a generalized solution. What we have currently was made for a very specific purpose: import into the RoboMaster software used by scrapbookers to generate GSD files for their desktop cutting plotters. The purpose for the very specific label was to avoid misleading anyone that this should fulfil the role of generic DXF output. I'm a little bit anxious to make changes because it works for this specific purpose as it is.

So the question is, do we role your changes into the desktop cutting plotter output, and perhaps rename so that it is seen as a generic DXF output? (There is some benefit to having the specific label too. Scrapbooking users can see it and know "this is for me".) Or do we separate the two, leaving the old to fulfil the specific purpose and making a new more generic DXF output where people can put in the hard work of making it applicable to the greatest number of scenarios?

I think we're too late in the release cycle to put this change in now, because it could possibly have a negative effect on the scrapbook users. But let's get together on email or IRC and hash this out and get it in, in some form, after the release is branched.

Thanks for your work and research!

I think SPLINEs can contain a few different types of "curve" possibly including polylines. The SPLINE curves we use here are NURB curves. So there is some conversion necessary from Inkscape's cubic beziers and I have no idea how to get beziers back out of the cunverted NURBs. :-)

Hello Aaron,
 I am tempted to try to limit the scope as much as possible, partly because the full scope of the job is somewhat daunting and partly because there are other efforts such as DXFLIB already working on this in a general way.
 I guess my question is: do the cutting plotter applications actually use the spline or are they using just the line, because the line is probably not going to be affected in any way by this. Any changes that I suggested for the line were purely cosmetic, not substantive. At the worst there may be some new attributes which hopefully a device can ignore if it doesn't recognize them. Even the spline is not really affected numerically, all the numerical data are the same as before.
    Somewhat off the topic, but there is another reason for wanting to limit the scope, namely that I don't think it will ever be feasible to produce a 100% clean output completely automatically because the code currently does not interpret or use the 'transform' attribute afaik. It is necessary to manually force the removal of 'transform' before doing the output. In my opinion this is an Inkscape problem, not a dxf output problem, but it does impose a limitation on the scope of the job, no matter how we decide to implement splines.

Yes, the cutting plotters do interpred the SPLINEs. RoboMaster doesn't
like to re-edit the SPLINEs and crashes if you attempt to move a control
point, but it did this for DXF files created by other exporters too. I
think this crash is a result of RoboMaster expecting only the subset of
SPLINEs that it is able to create, but I need someone more mathy to
prove that.

Are you at all skilled in C++? There was a generalized DXF input/output
written for GSoC a few years back. It went a long way toward solving the
problem, but wasn't integrated because of some security issues, iirc. I
seem to remeber that it was even able to render 3D DXFs into 2D for import.

Have been trying to decide how to decide whether to integrate everything or not. I think we can decide as follows: I believe that the spline we are using requires at a minimum AutoCAD Release 13 (code AC1012 in a dxf file). Release 13 also has a number of other new features which appear to be mandatory (in the ENTITIES section) :
1. use of unique handle for each entity (code group 5)
2. use of term AcDbEntity for each entity (code group 100)
3. use of term AcDbLine or AcDbSpline for each entity (code group 100)

All these elements exist in a Release 13 file, none exist in Release 12.
Any attempt to remove any of these elements in a Release 13 file immediately makes it unreadable, using my viewers.

So the question will hinge on whether Robomaster can interpret or perhaps just ignore these three elements, because they are mandatory. If it can, then we should be able to integrate everything into a single package, if not then not.

As to the C++, I can read it but it usually gives me a headache. I use C at work, but it is the old style before the (++) part. I recently downloaded the source code for dxflib 2.2.0 and took a quick look at it this morning. It has many references to handles and seeds and so on, so I will check it out some more over the next few days.

The DXF2SVG code that Aaron refers to is still lying around in the
inkscape source tree in src/extension/dxf2svg/*, in case you are
interested in checking it out... It seems to actually compile to a
standalone executable that, as you might expect, converts dxf to
svg...

Hmm... The README in that dir reads, in part:

"What is supported:
polylines, lines, arc, circles, blocks, text, and a little linetypes

currently not supported but I hope will be in the near future
(probably after Sept 05)
layers, colors, trace, splines, dimentions"

new template dxf file

    I toyed briefly with the idea of submitting a diff, until I realized that I can't because I don't have svn.
    However, in the meantime, I have removed the original versions of dxf_outlines.dxf and dxf_outlines.py and have replaced them with new versions.
   The new versions are significantly smaller and totally generic, with no references to any specific hardware devices.
    They are based on a dxf file generated by pstoedit, using AutoCAD Release 14 format. The template file was reduced in size by removing elements one-by-one until it became unreadable by Voloview. The new template file is 5231 bytes compared to the original 15860.
    Voloview is a more difficult reader to satisfy than DWG TrueView (see comments in file drvdxf.cpp, which is part of pstoedit), but DWG TrueView gives much better error messages, so both were used to test the final output.
    I believe this will be compatible with the previous submission, please let me know if it doesn't work.

Alvin, what would you think about adding r12 dxf output as an option by using the same method as used in flatten.py to convert the curves to polylines?

I also think we should make the scale configurable. do know what other common scales would be needed?

Committed revision 17754.

I made a few changes. Looping through the dxf template file a magical number of lines looked fragile to me so I made the dxf file into a python module with two long strings. Let me know if you object.

Hello Aaron,
    Thanks for the feedback, I run the win32 nightly builds, so I will download one the earliest opportunity, which I think will be Wednesday.
    I made a rather embarrassing discovery yesterday, which almost makes me think I was just spinning my wheels for nothing, as they say. I installed a demo version of QCad which is time-limited and discovered to my shock and amazement that it can read everything perfectly, both the original desktop cutting plotter output and the new version, and they are completely indistinguishable. (Well, the color attributes may be different, but who cares about color in a line drawing?) So now I understand why nobody had a problem with this except for me. In my world everybody uses Voloview, but the Inkscape world probably uses QCad. In terms of level of difficulty of getting input requirements satisfied, the hierarchy is as follows:
    QCad < DWG Trueview < Voloview
Most people would not use Trueview because it is humongous, its only merit being that it has nice error messages.
   Anyways, I predict that no one will even detect that a change has been made, but I will respond back here as soon as I see the new version. Thanks for the help.

Yeah, I use QCad. And it always worked there. But if we can support a
much wider field of users with just a few simple changes, I say go for it.

Did you have any ideas about the scales needed to support other software?

I have access to Autocad Lite at work, so I'll do some cross-checks between Inkscape coords and Autocad coords and see how they match up.
   On a somewhat related subject, is it possible from a python script to read an Inkscape preference value like "Default Export Resolution", which I think was originally 90 dpi, but can be changed by a user?

- Testing the change in revision 17754
- downloaded the win32 build 0803131626.7z
- corrected minor typo in file dxf_templates.py
- am attaching the new version of this file
- ran the desktop cutting plotter on the file Venus_and_the_half_shell.svg and viewed the dxf output file in Voloview Express.

Looks good to me, thanks a lot!

I had the same problem importing .dxf files generated from Inkscape to Autodesk Inventor 9.

I downloaded dxf_outlines.dxf, dxf_outlines.inx, dxf_outlines.py and dxf_templates.py from above and copied them to
C:\programme\Inkscape\share\extensions

Now it works fine! Thanks for the fix!

Milestoning for 0.47. Did anyone commit this to trunk?

just writing to confirm that, yes, this has been released, and it has been tested, and it works well, as of about March 29

Has anyone tested this with robomaster? Seems to be a concern in earlier comments.

Anyone connected to robomaster, you might also like to look here - https://bugs.launchpad.net/inkscape/+bug/180165

I should clarify the nature of the change that was made...
Previously these dxf files were viewable in QCad but were not viewable in Voloview or other Autodesk products because these other programs sometimes have more stringent syntax requirements. With the modification these files are now viewable in Voloview.

I don't know if this belongs here or not so forgive me if it does not.

Even with the fixes as described above, I'm still have problems importing a .dxf file, exported by Inkscape, into Summa Inc. plotting software called WinPlot. It is used for plotting and vinyl cutting. My .dxf graphics lose their curvature continuity (spline discontinuities) and even some of the bezier curve verticies (I think their bezier curves, I could be wrong) get moved from their original place. I've also had problems importing .eps files ,also exported by Inkscape, into WinPlot. This is described more thoroughly in bug #168411. I found a way to get around the problem though that might be useful in the future if Inkscape is interested in exporting Adobe Illustrator files. what I've done is export the graphic from Inkscape to a normal postscript document. Then I use the freeware utility called pstoedit to convert it to a adobe Illustrator graphic (*.ai). It loads up just fine and dandy in WinPlot and I've had no problems with it. I don't know how the rules work, but someone might be able to put this procedure into a patch or incorporating it into Inkscape to actually output into Adobe Illustrator. It would be very useful to the sign making users of Inkscape. It would also make it so we wouldn't have to deal with the problems of .dxf. Granted, I'm not fully aware of the new problems and bugs that could arise from this. It probably creates a very basic graphic that you wouldn't be able to do much with in Adobe Illustrator itself. But that's why I use Inkscape: I create the graphic I want to cut, and then export it as an adobe illustrator file so my cutting software knows what to do with it. You don't need anything fancy.

sorry it was so long winded.

could you attach an .svg file that you would like to convert to .dxf ?
I will try to do this conversion on my machine

Alvin,

My wife is starting a hobby for inspirational sign making so forgive the example I am giving you. This is simple text that has been converted to paths with the fill subtracted and the stroke added. I think that only thing else that we might be interested in doing beyond this simplicity is then stoking the text to a curved path or something to that nature. I hope this helps you. I will also include a screen shot of what it looks like in Winplot after conversion to the .dxf.

Have fun and happy hunting :)
Andrew

The screen shot. As you will notice, the .dxf after importation into Winplot loses the nice smooth curvature of the text. There are even some spots the lines of a letter will cross over one another.

Hope this helps,
Andrew

thanks, I'll look at it

    Thanks for the tip concerning Summa Winplot. I've installed Winplot and run a few comparisons using .dxf format files. As far as I can tell, the problem with .dxf files is in the rendering that Winplot uses.
    A typical .dxf spline curve consists of four points : a start point, 2 control points, and an end point. (where the start point may be inherited from the previous spline.) What Winplot appears to be doing is using the first three points to define a circular arc, and then using the last point as the end point of a straight-line segment, which starts at the third point. The final result bears no relationship to a Bezier spline.
    Interestingly enough, their treatment of .ai files does not suffer from this defect, so it should be quite easy for them to fix this.
    I will try to contact them to see if they would be interested in investigating this.

attached is a response from Winplot to my question about the .dxf rendering procedure .......

Dear Alvin,

Winplot has limited import filters and is free.
So modifying is not a direct option, it could be the end of WinPlot
being free..

I think you want Winplot to work with Inkscape is that it?
If so , then I propose to do following:
Make sure all your objects are outlines, no fills (preferably hairline)
When using text immediately change it to paths in Inkscape itself,
before modifying it (scaling or rotating).
Make sure your design stays within the page size.
When exporting (or save as) use the option 'postscript via Cairo'.
Do not use 'add extension automatic'.
And give as filename xxxx.eps.

Summa does not support Inkscape officially.
The reason for that is that the program changes often (because of it
being open source).
But that is what I found out by playing around a bit with simple shapes
in Inkscape during my free time.
Let me know how it turned out.

Best regards,

Wim Vanraepenbusch

-----Original Message-----
From: Alvin Penner [mailto:<email address hidden>]
Sent: maandag 9 juni 2008 1:53
To: Tech Support
Subject: .dxf import into Winplot V6.80

Hello,
    I apologize in advance if this is a duplicate message, I just sent
this message to the usa office as well.
    I am writing to report what appears to be a rendering problem when
using Winplot to import .dxf files that contain cubic Bezier splines.
What is happening is that the spline is being rendered as a combination
of a circular arc and a straight line, not a cubic Bezier spline.
    I am attaching three files. The source file is testwinplot.svg. It
consists of a single cubic Bezier spline, done as a thin solid black
line.
In order to show exactly where the control points lie, I have also added
a multi-segmented polyline done as a thick green line.
 The second file is testwinplot.dxf. This is the dxf version of
the same file. When viewed in AutoDesk Voloview Express 2.01 it shows an
image that is identical to the .svg file, except there is no green
color, just two separate black objects. When viewed in Winplot 6.8, this
file shows the multi-segmented line properly, but the Bezier spline has
been rendered as a combination of a segment of a circular arc plus a
straight line, neither of which are true to the original spline shape.
      The third file is testwinplot.ai. This file is displayed properly
when viewed in Winplot 6.8.
      So my question is, would it be possible to modify the .dxf
rendering routine to make it compatible with the .ai rendering routine?

Thank you for your consideration,
Alvin Penner

Hello,
I just found this thread while trying to export dxf from Inkscape to open in Autocad (2008). With the files above it really works better now. One problem that i found:
All the Inkscape paths are split and converted into Autocad arches but they are not joined together as it should be in my opinion, so you have to do it by hand. Maybe this functionality could also be added?

Oh, one second thing that i found is, that when you open the dxf in Autocad it is really huge. Everything is scalled by a factor of 100 or something like that, so at the moment i have set the document size in inkscape to 10 mm by 5 mm to do a 1000 mm by 500 mm drawing. Sorry for posting twice but i did not find an edit button for my last post.

Hello Johannes,
    Thank you for the feedback, it is always good to hear from someone who actually uses AutoCAD.
    - with respect to the first comment about joining arcs, I will take a look at this after Christmas to see whether it is feasible to do this. I am assuming that what you mean is that a single svg path element should be rendered as a single dxf spline (or multi-spline) which does not break apart when you edit the internal nodes in it.
    - with respect to the scaling, when scaling the dxf output, it is assumed that the svg image has a resolution of 90 dpi, and that the desired dxf output is in mm. So all svg coordinates are multiplied by a factor of 25.4/90.0 when generating the dxf output.

Thanks for the answer. At the moment i am trying to contact my cousin to ask him what format the Autocad file should have so that it can be used for CNC cutting.
For the scaling problem i will make some test this evening if i have time. The thing is, I have set the units to "mm" in the document properties of Inkscape but i don't understand exactly what you mean with 25.4/90 scaling.
I just saw when you sketch something in Inkscape without changing the properties and export to dxf, in the most cases it will be to huge to be opened in Autocad. I think then Autocad will only read/display the down-left corner of the dxf file. At least that is what it looks like.
By the way are there any options when selecting save as -> dxf? I did not see any options/properties menu or something like that...

Ok, I made a little test. Fired up Inkscape drawed a line with some markers, moved it to the down-left corner, saved as dxf and opened in autocad. (See attached svg file)
The result was that only the first marker could be seen in autocad. The rest of the drawing was cut off. So there must be a problem with scaling or maybe the size of the page is just set to a wrong value in the dxf file.
By the way did you know this guy? http://www.bobcookdev.com/inkscape/inkscape-dxf.html
Maybe you could work together. For me the problem in his plugin was that it converts everything to connected straight lines instead of arches.

I am going to temporarily mark this as Fix Committed instead of Fix Released so that it is visible to other people, otherwise it is hidden from normal searches. If we come to a satisfactory resolution, I'll return it to "Fix Released" status.

- as to scaling, this is very embarrassing, but when I load the dxf into Voloview, the units show up as inches not mm., which I guess is why your drawing is so large. The numbers are numerically correct for a mm drawing, but the units are being misinterpreted. I will see if I can fix this. The viewers that I use don't really care about units, they just scale everything to fit the page or the screen, so this was never an issue, but in AutoCAD it may be a problem. I'll see if I can fix this.

- as to bob cook, I was not aware of his work, but it looks extremely interesting, and he should probably be encouraged to contribute directly to Inkscape. Thanks for finding this reference.

- as to my own personal plans, I am interested in development that preserves the precise mathematical shape of the paths or splines, so if there is a practical motivation for developing a multi-spline, I would be interested in pursuing that.

    I am attaching a new version of the template file. In Voloview this has the effect of converting the display units from inches to mm while keeping the same numerical value for the data. Would you be willing to test this in AutoCAD to see if it helps?
    You'll need to rename it to be dxf_templates.py, and first make a backup copy of your existing file, just in case.

hth,
Alvin

Hm, I don't see the new file changes anything.
The thing is sometimes when i play a round a little bit with the different views in autocad suddenly i am able to see the hole drawing, but never from the beginning. I will do more testing later this evening...
See screenshot to see how it is cut at the beginning.

Ok now i know how i can see the complete drawing in autocad. There is a button called "extents" (see screenshot)

But I don't think that this is the optimal solution. Better if you could just open it like that.

    yes, I have a similar situation in DWG Trueview, I need to rescale it there as well. I do not have access to AutoCAD, would you be willing to upload a template file that I could use? Ideally it would be a blank page in dxf format, size A4, portrait orientation, default units of mm. Perhaps I could use that as a template for my output,

Thank-you,
Alvin

Ok, i can give you some blank dxf files when i am back home, but there are different versions. Do you want the newest? I think it was 2007 or maybe 2004...

thanks, I don't think the version number will matter, either one is fine.

Ok, i just started autocad and did -> save as -> autocad 2007 dxf.
It says in Page Setup Manager: Plotsize: 210 x 297 mm (portrait)

When i looked at the source code of the template.dxf I saw that there was a line with my name in it.
I deleted it an it still works. So here is the updated version. I hope there are no more personal informations in it...

thanks for the file, I'll see if I can extract the scaling information from it. This may take a while, scaling in AutoCAD is more difficult than I expected.

What about the documentation? http://images.autodesk.com/adsk/files/acad_dxf0.pdf
See Page 13 for an overwiev of all the header variables. Maybe you allready know that.

Why you don't just take the HEADER from the template file?

I think the variables we are looking for are probably $EXTMIN and $EXTMAX. But i am not sure...

    Attached is a new version of the templates file. In DWG Trueview this has the effect of generating an initial display in Model Space which is 297 mm. high.
    This will need to be renamed to be dxf_templates.py before using.

hth,
Alvin

Hm, doesn't change anything in autocad. Now that I know that i can use this extents button to solve the problem, it is not such a big deal for me but it would be cool to just open it in the correct size. I hope my cousin will answer my mail so I can tell what is important for CNC.

    sorry to hear that, the change that I made was to rescale the size of the first VPORT in the TABLES section. This rescaled the initial image in DWG Trueview, and it had no effect in Voloview, which was already scaled properly anyways. I have confirmed that the parameters $EXTMIN and $EXTMAX do not affect the initial image, although they may affect the scaling behaviour when you zoom to extents. In any event, I will keep it in mind if any new ideas come up. I occasionally have access to AutoCAD at work, but not on a regular basis.
    I am quite interested in the CNC behaviour. I know that in the old days, as in AutoCAD Release 12, CNC machines could not actually process a true spline, and in Release 12 the true spline does not exist, instead you get hundreds of connected multi-lines which is what the CNC machine required. So I am curious to see if the new CNC machines can directly process a spline curve.

Ok, i talked to my cousin a few minutes ago and you where right, the CNC machine can only process polyline and no spline curves. Would it be possible to make that optional or to have 2 dxf ouput filters, one for splines and one for polylines?
Second problem is with text. Text must also be polylines or the CNC will kind of think that there are thousands of single lines and that would not have some nice results.
Would be cool if you could do the polyline thing till next weekend because I am currently drawing the christmas present for my Brother with inkscape :)

    yes, I was afraid that this might be the case, the problem is that physical machinery likes to move in a straight line, no curves.
    what I would recommend is that you investigate the Inkscape menu option called :
Effects | Modify Path | Flatten Beziers
    with this effect you can take a Bezier path or a spline and you can convert it into a multiline, and you can specify the precision or the length of each segment. You can also do the same with text if you have previously used the menu option called Path | Object to Path.
    once you have converted the splines into multilines like this, then you can export to dxf and the result will be readable by a CNC machine because it will be all lines, no splines. The choice of precision in the output may be difficult, not quite sure how to do that, best thing is to zoom in and look at it.
   I have no experience with doing this kind of conversion, but I would recommend asking a question at http://www.nabble.com/Inkscape---User-f1927.html
or check out : http://sourceforge.net/mailarchive/forum.php?forum_name=inkscape-user

Did some more reasearch on the topic. Found that Inkscaspe uses pstoedit to convert .svg to .ps and after that to .dxf. Is that correct?
Next thing I did was downloading pstoedit (ghostscript was also needed) to see what additional options it has when converting.
Look for pstoedit dxf options here: http://www.helga-glunz.homepage.t-online.de/pstoedit/pstoedit.htm#section_49

First I tried the different options for spline and polylines.
There are 3 that worked:
-splineaspolyline together with -splineprecision number (I think this is what bob cook does)
-splineasmultispline (this seem to be your implementation)
-splineasbezier (this generates some other types of splines...)
What is missing in my opinion is a way to convert curves into autocad arches which i was able to convert to some kind of curved polylines
That is the way how some tools (for example http://www.techni-soft.de/html/SplineExplode.htm) are doing it.

Second I noticed when converting like this: "pstoedit -f "dxf:-option1 -option2" deinegraphik.ps deineknovertiertegraphik.dxf"
I don't have the scaling problem any more. option1 should be -mm then autocad seems to recognize it pretty well.

Oh, I did not read your last post before i wrote mine because I had allready started to write :)
I forgot to say another important thing I found:
When doing the conversion like this: "pstoedit -f "dxf:-mm" input.ps output.dxf" (notice there is a difference between format dxf and dxf_s)
without specifing other options than -mm it seems to be the best way to convert text. Because every single letter will now consist of a closed and connected polyline instead of a bunch of unconnected single lines.

Inkscape 0.46 contained two types of dxf output : "AutoCAD DXF" and "Desktop Cutting Plotter" output. The "AutoCAD DXF" output used the program pstoedit. To the best of my knowledge, this option is no longer supported in the development versions of Inkscape, but you can run it by yourself, outside of Inkscape.

Ah, I see. So now Inkscape has it's own functions for exporting dxf. But maybe you can learn from pstoedit how to fix the problems with scaling and text conversion.

Glad to hear that pstoedit worked.

I am going to mark this as Fix Released again; if any new issues arise, then probably the best thing to do is raise a new bug report.

    I have done some comparisons of the .dxf output from pstoedit and the output from "Desktop Cutting Plotter". I see that the pstoedit dxf output is from AutoCAD Release 12, and uses the POLYLINE entity. This has the property that it does not break apart when edited. This would be very convenient if one had previously used the Inkscape procedure "Flatten Beziers" in order to produce an output compatible with a CNC machine.
    I would be willing to try to implement the idea of a POLYLINE output: however, it will have to wait until after Christmas since I have not yet done my shopping ...

That sounds great. Waiting is no problem for me now since I can use a combination of all the tools to get the desired results. But it would be definitely cool to have everything integrated in inkscape.
Do you think you can also fix the problem with the text? See the text.dxf example file to see what i mean.

I think so, yes. I'm assuming that what you are referring to is the mixture of LINE and LWPOLYLINE entities. I think this could be resolved.

It is important that the lines are connected like on the left letter in the example file because i was not able to "join" them in autocad, so it will not work with CNC...

I have to report another bug with dxf export I often encounter. When the dxf file is opened in Autocad and I try to save it again in Inkscape, then Inkscape crashes completely instead of throwing some error message like "file could not be accessed!"

I have not been able to reproduce this behaviour when opening the dxf file simultaneously in DWG Trueview and doing multiple saves from Inkscape. It is possible that this behaviour may be unique to AutoCAD. Perhaps AutoCAD is locking the file in a manner similar to what database programs like Microsoft Access sometimes do.

Yeah, you are right autocad is somehow blocking the file, but this should not make inkscape crash. Because there is a great danger of loosing unsaved data!
Do you need aditional information in order to fix this? Maybe a screenshot or something? I think there was some kind of error message but when you click OK inkscape crashes. I will make some screenshot when I am working with my windows partition next time. I do not have autocad on linux...

    yes, a screenshot would help. If this is a Python error message then I could look at it. If this is an Inkscape crash, then I would recommend reporting is as a separate, new, bug, because the same problem will also be encountered by other export programs, not just the dxf program.
    Also, if you are getting an actual crash in Windows, then you can often trap useful exit messages by running Inkscape from a DOS prompt and using the methods outlined in http://kaioa.com/node/63

okay, I take that back, I have been able to produce an Inkscape crash by manually forcing a dxf file to be read-only in between successive saves. This is the type of condition that could probably be detected from inside a Python file, so I will take a look at it.

    okay, I take that back, again. I am not able to detect the status of the output file from inside the Python code, because I do not know the file name. The Python code apparently writes to a temporary output file, not the final destination. So I cannot fix this crash that is caused by a read-only output file.
    I have confirmed that this type of crash is common to all the export routines that I am aware of that use Python extensions, so it is not unique to .dxf.

Could someone please file another bug about the read only output file issue? I'm afraid that it will just stay burried here.

good idea, done at Bug 309856

    the file dxf_outlines.py has been modified to replace all instances of the LINE entity with the LWPOLYLINE entity. This will be most noticeable when using the menu item Effects | Modify Path | Flatten Beziers. The LWPOLYLINE has the property that it does not break apart when edited, either in QCad or in ROBO-Master.
    This change will affect all line segments both in QCad and ROBO-Master, but it will not affect any splines in either program. Individual lines turn out the same regardless of whether they are called LINE or LWPOLYLINE.
    The polyline has been tested in ROBO-Master Pro Version 4.30, to confirm that the polyline is editable with no breakage and no crashes.
    - committed to svn 20394

With Flatten Beziers it works quite well :) Thank you.
Only little problem now is the scaling thing. For that we need to find out how to set the units to mm.
You can see the files "dxfacad.h" and "drvdxf.cpp" in the psotoedit sources to see how it is done there. Search for "MEASUREMENT"

good to hear,
I will investigate the scaling some more in the new year when I have access to a machine with AutoCad on it.

    okay, my curiosity got the better of me. I am attaching a trial version of the scaling test, can you tell me whether this loads properly into AutoCAD?
    I have modified the dxf header to make it more compatible with the pstoedit header.
    When I load this into DWG Trueview I get the initial display in Model Space with a minimum y value of -21 mm and a maximum y value of 319 mm. The border at the top and bottom is deliberate, the pstoedit header specifies the total height to be 340 mm. (I had previously used a value of 297 mm for this parameter.)

I saved the file as dxf_outlines.dxf. It doesn't change anything in autocad. Page Setup still displays inches and not mm.
I have attached a file which i converted with pstoedit and which is displayed in mm in autocad.

    sorry, I may have misled you with this file. The file dxf_test_Dec24.dxf will not modify the output of the dxf program in any way. It was sent simply as a demo file to see if it would load properly into AutoCAD as is with no changes.
    I have compared the headers in the pstoedit file with my header and cannot find any significant differences between them, I will investigate this some more next week when I am back at work, but I am curious whether you could load the dxf_test_Dec24.dxf directly into AutoCAD.

Hey this is cool! It works. Excellent.

good to hear, I am attaching the latest version of the file dxf_templates.py .
- this has been committed to svn rev 20415

Hey this is great. Thank you very much. Will it be part of the next Inkscape version?

yes, these changes have been incorporated into the development version, which will become the next release eventually, and is available at http://inkscape.modevia.com/win32/?M=D