proposal for .dxf input

The scope of this extension has been limited to those dxf entities that are easily, and mathematically precisely, convertible from .dxf to .svg.

Also, the extension will convert only AutoCAD Release 13 and newer files, but earlier dxf versions can normally be converted to Release 13 using QCAD, before using this extension.

Any feedback would be greatly appreciated

committed to svn rev 20154

Hi Alvin

I have made a copy of the dxf_input.inx and the dxf_input.py files to the extentions folder, but nevertheless Inkscape cannot recognize the dxf files i made from my Cad-software.

Do I need to import the file somehow to Inkscape?

I tried both to open and to import the dxf files, but none of these shows the *.dxf file support.

Best regards,

Mads Boserup Lauritsen

hi, thanks for the feedback
I'm going to assume that you are probably running Inkscape 0.46, the stable release.
In this case, you'll need a different version of the .inx file. You will need to take the attached file, dxf_input_46stable.inx, rename it to be dxf_input.inx, and save it in the directory C:\Program Files\Inkscape\share\extensions\ to replace the existing file that is there.

If all goes well, then when you try to use File | Import or File | Open, and if you check the file types, there should be a file type "AutoCAD DXF (*.dxf)"

hope this helps, and feel free to submit any .dxf files that are not performing as expected

Alvin

Hi Alvin

Thx for the quick reply. It works with the file for the stable 0.46 version of Inkscape (Sorry I forgot to mension, I´m running windows XP, if it has any interest...)

I have tried to import the attached files.

The first has the error as described below, while the two others can be imported, but with some issues.

The file "floorplans_test_inkscape.dxf" is a multiple layered floorplan drawing and it gives the following error

"Traceback (most recent call last):

  File "C:\Program Files\Inkscape\share\extensions\dxf_input.py", line 181, in <module>

    entities[entity]()

  File "C:\Program Files\Inkscape\share\extensions\dxf_input.py", line 40, in export_MTEXT

    node.text = vals[groups['1']][0]

  File "etree.pyx", line 652, in etree._Element.text.__set__

  File "apihelpers.pxi", line 321, in etree._setNodeText

  File "apihelpers.pxi", line 558, in etree._utf8

AssertionError: All strings must be Unicode or ASCII"

Maybe it is to complex for this preliminary test of the dxf-import? It has around 3000 entities..

The two other files was imported without any errors, though they do not shows lines, if these where in blocks in Autocad, eq. doors etc. The format is autocad 2000/lt2000 dxf

The first file floorplans_test_inkscape_simple_test01.dxf is with blocks.
The second file floorplans_test_inkscape_simple_test02.dxf is the same drawing but exploded blocks.

Both can be imported, but the first lacks several lines (those in blocks and hatches) while the latter both shows the exploded blocks and hatches.

Regarding scaling the imported dxf-files, the first one is imported and placed in a "far-out" x,y coordinate, while the latter is situated close to the page coordinates. (Are there a way to implement a scaling factor while importing?)

I hope you can use my feedback in a constructive way, It looks very promising. If there are any specific issues you would like to have tested please let me know.

Best regards,

Mads Boserup Lauritsen, Denmark

hello Mads,
    Thanks for the feedback, this is exactly what I was looking for!
I've downloaded your dxf files and confirmed that they are viewable in Voloview, which is my normal viewer, since I don't have AutoCAD.
    three quick comments,
1) I probably will not implement any support for BLOCKS, since I don't fully understand what they are.
2) I will definitely try to fix all crashes, since a program like this should never crash
3) I will try to see if I can implement some automatic scaling, since I assume that the dxf file probably contains all the scaling information I need, except that I am not using it. I will probably try to scale the original image onto an 8.5 x 11 inch final page.

    anyways, thanks for the feedback, it will probably take me a month or so to respond, but I will post the result here

Alvin

Hi Alvin

I do not know how these extensions works for the Inkscape in genereal (I have unfortunately no knowledge in programming, and is new to the Inkscape project, but a experienced user in both Autocad and the Adobe-package, but looking extensively for Opensource alternatives..). If there is to be written any user-guide or hints for the "dxf-import", or I can help in any other way, please let me know.

ad1: Could be implemented in the user guide "dxf-import does not support block-import, please explode blocks and hatches before importing your dxf-file".

ad2: :-)

ad3: As I have no knowledge in programming, please correct me if this wish is to much!! Is it possible to instead of scaling to a standard "letter format" to make a choice that says "scale to media"?

Example: I work on a "5inch x 5inch" or a "1meter x 1meter" sheet, and the dxf-import tool will scale it so it fits directly to the working space.
Of course it is possible to rescale the imported vector-file in Inkscape if it the script scale to an 8.5 x 11 inch page, but just a thought.

------
When I draw polylines in Autocad, these where imported as single lines in Inkscape, is this a default, or can the dxf-import convert closed polylines to closed vector-graphics in Inkscape?

If I where interested in getting knowledge in basic programming, so I somehow could tribute to the development with other things than "demands".. where do I start? Or is it more serious to join as a "bugtracer" and maybe by donation contribute to the project? (I am working as an professional urban-planner, has knowledge in databases, mathematics etc..)

Best regards, glad you could use my feedbacks

Mads

adding new version of dxf_input.py.
this has been committed to svn rev 20254
The following changes were made:
- some limited support for colors, Group Code 62
- support for multi-line output in MTEXT
- support for TEXT, identical to MTEXT
- support for automatic scaling based on $EXTMIN and $EXTMAX

comments :
- have not been able to reproduce the above crash, maybe it is unique to 0.46
- I do not know how to read the dimensions of the target svg file so I have assumed arbitrarily that it is an A4 page. The size of the source document can be obtained from $EXTMIN and $EXTMAX, if they exist. If they do not exist then just standard scaling from mm to px is done, as before.
- with these changes the file floorplans_test_inkscape_simple_test02.dxf renders reasonably well.

Hi Alvin

I downloaded the new dxf_input.py file, and everything renders very well. (The old files, renders with text and it is editable in Inkscape)-

In this test of the dxf-import, I used a new project for the dxf-files, and made one file with blocks and one with exploded blocks. ( I attached the two dxf-files and the result I get as *.svg).

Both dxf-files renders the text (first 3 lines where made in MTEXT, the 3 last in TEXT), and it is editable. I drew a box of 50x50 meter in Autocad to get some kind of scalable dimension into the dxf-files.

The one with blocks make some funny line renderings, best shown in the attached svg-file...

ad 1. Everything came in as black lines, what does group code 62 mean?

ad 2. The text is shown, and editable.

ad 3. Same

ad 4. The imported files appears close to the page layout.

comments:
Nice work :-)
Polylines are imported as line-segments :-)
,as I did not try in the first test if closed polylines where imported as line-segments I do not know if this is a fix in the new *.py-file, but nice work anyhow :-)

Can I somehow be at some assistance, please let me know.

Best regards,

Mads

- adding new version of dxf_input.py
- this has been committed to svn rev 20286
- added support for color BYLAYER

Group code 62 is an index to a color table with 256 entries.
Previously this could be used only in individual entities, but now it can be used BYLAYER which is probably the more common usage.

Works well on the files I uploaded earlier,

are there any specific things you want to be tested?

The color bylayer is very usefull, good work :-)

Best regards

Mads

   thanks, and thank you for the testing and test files. I am not an AutoCAD user so it is hard to get good samples to work on. I just learned how to use the explode Block feature in QCAD, which seems to do the same as in the trial files you supplied, and yields a similar improvement when converted to svg.
   I have no immediate plans for further development, unless new problems are reported, so I will probably mark this as fix released in a week or so.

If you need a more advanced Cad-program I can suggest BricsCad. It is based on the Intellicad-code, which used to be Opensource. They have a 30days trial version, where all commands are accessible. They have a stable version for Linux. The program cost 315-450$, and for me as a professional a good alternative to AutoCad above 3000$ prices (for the light version...).

I am changing from AutoCad to BricsCad, but check out the trial at www.bricscad.com, if you need a more advanced testing tool (for a month).

Said it before, but nice work with the script :-)

Best regards

Mads

ps. Opened the *.py file in a text editor, as far as I can see I will stay as a tester for a while, a let guys like you take care of the programming :-)

thanks for the info, I'm going to mark this as 'fix released'.
if any new issues arise, perhaps a new bug can be raised.

Alvin

Hi,

While using the latest plugin posted here, and using the version0.46 when open or importing this error is raised

Traceback (most recent call last):

  File "C:\Program Files\Inkscape\share\extensions\dxf_input.py", line 238, in <module>

    entities[entity]()

  File "C:\Program Files\Inkscape\share\extensions\dxf_input.py", line 51, in export_MTEXT

    tspan.text = text

  File "etree.pyx", line 652, in etree._Element.text.__set__

  File "apihelpers.pxi", line 321, in etree._setNodeText

  File "apihelpers.pxi", line 558, in etree._utf8

AssertionError: All strings must be Unicode or ASCII

Forgot to mention that this file is generated by Solid Edge 2D Drafting and opens well in Ilustrator and QCAD.

Another thing to mention is that I opened the file with Textpad and saved it as Unicode and in a second try as Unicode(big endian), both opens the dxf file without any error but nothing shows.

thanks for the feedback, I have been able to reproduce this problem, will look into it on the weekend.

Attached is a new version of dxf_input.py which will load the file patim.dxf.
The problem was non-ascii characters.
This has been committed to svn rev 20354.

Now it doesn't throw the exception anymore but its doens't render right

I've made a printscreen from Inkscape vs Illustrator rendering

Thanks for the hard work :)

    yes, there is a problem, this image contains a type of spline that is not supported by the code at the moment, and so it is ignored.
    I think it will probably be feasible to develop some support for this type, not yet sure if it will be mathematically exact or not, will look at it after Christmas.

- added support for a quadratic Bezier spline, modified code is attached.
- I believe the file patim.dxf is now being rendered completely.
- committed to svn rev 20398

Yes it solves that rendering problem. I 've tested some more files outputed by solidedge and all are rendered right, one thing I've noticed is that the sclae is not accurate but Im not shure of it, I'll run some more tests to assure that everything is ok.

thanks a million

just a note on scaling :
what the program does is read the parameters $EXTMIN and $EXTMAX from the dxf header, if they exist. It will then use these parameters to fit the entire drawing into the width of an A4 page. If these parameters do not exist then it will use a standard scaling based on the assumption that the dxf drawing was done in mm. and that the Inkscape screen resolution is 90 dpi.

I installed the new extension, but I don't even get an option to import a dxf, did I miss something.

Hi, thanks for the feedback. I'm going to assume you are running 0.46 stable version, in that case refer to a previous comment :
https://bugs.launchpad.net/inkscape/+bug/293940/comments/5

you'll need to download the file dxf_input_46stable.inx and use it to replace the file dxf_input.inx

hth,
Alvin

Hi Alvin

Good to see that other users are making use of your script.

I have been looking more into Inkscape the last couple of days and found, to my regret, that is not possible yet to select all entities with example "green color stroke" or by fill-color.
As your script support the "color by layer" in the dxf-import, is it possible to make preserve the layers from the dxf into the svg?

So that the rendered dxf >> svg file will have different layers from the original one?

Best regards, (and happy new year)

/mads

interesting idea, I will put that on my list of things to think about. Each layer in Inkscape has a different group id, and I am not familiar with how to navigate to different groups when generating these svg paths, but I will try to take a look at it before the release of 0.47.

Cheers,
Alvin

the file dxf_input.py has been deleted and replaced with a new version.
this change has been committed to svn rev 20608.
the new version supports layers, so the .svg file should contain the same layer labels as the .dxf file.

Note that this works only on a File | Open, not on a File | Import.
A File | Import will lose the layer information in the .dxf file, for reasons that I do not understand. However, the same behaviour is true for imports of a regular .svg file with layers as well, so I assume this is by design.

Hi Alvin

:-)

Works fine with my files.

Excellent work.

Best regards

Mads

good to hear, it turned out to be easier than expected.

Alvin

Alvin Penner wrote:
> good to hear, it turned out to be easier than expected.
>
> Alvin
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.16/1929 - Release Date: 2/1/2009 6:02 PM
>
>
Nice job Alvin, the new dxf input file works as expected, nicely done :-)

Using the file from post https://bugs.launchpad.net/inkscape/+bug/293940/comments/29 I get the following error message:

Traceback (most recent call last):
  File "/usr/share/inkscape-devel/extensions/dxf_input.py", line 249, in <module>
    entities[entity]()
  File "/usr/share/inkscape-devel/extensions/dxf_input.py", line 42, in export_MTEXT
    node = inkex.etree.SubElement(layer, 'text', attribs)
  File "lxml.etree.pyx", line 2342, in lxml.etree.SubElement (src/lxml/lxml.etree.c:21249)
  File "apihelpers.pxi", line 174, in lxml.etree._makeSubElement (src/lxml/lxml.etree.c:27048)
  File "apihelpers.pxi", line 246, in lxml.etree._initNodeAttributes (src/lxml/lxml.etree.c:27760)
  File "apihelpers.pxi", line 1323, in lxml.etree._attributeValidOrRaise (src/lxml/lxml.etree.c:36387)
ValueError: Invalid attribute name u'sodipodi:linespacing'

:(

I'm using the Inkscape development version http://ppa.launchpad.net/inkscape-nightly/ppa/ubuntu/
Interesting side note: the dxf_input.py was missing there (so I just copied the file from the posting on the 2009-02-01)

could you attach the .dxf file that caused the crash ?

Hello Chris,
      Thanks for the dxf file, I was able to load it successfully with no crash. Unfortunately, I somehow lost the email address, so I can only reply here. I have 2 email clients, and there was some confusuion between them (or me), and the actual email got lost.
    Anyways, attached is the source code that I used on Inkscape 0.46 stable which is not exactly the same as the newer development version of Inkscape. Perhaps you could try this on a simpler dxf file with no text to confirm that it works.
   Also, I should check, are you running Inkscape 0.46 or newer?

sorry, I just re-read your message and I see you are running the devel version, in which case you should keep the .inx file that you already have. But it might be worthwhile to try a simpler file to confirm that it runs okay.

okay, here is an experiment, could you try opening this file in Inkscape to see if it crashes ?

Hi Alvin,

using the Inkscapre-Nightly with the testsodipodi.dxf I get the same crash again (so there's no point in posting the same trace again...).

Using the 0.46 stable with your latest files of post #35 and the testsodipodi.dxf of post #37 I still get exactly the same crash and trace.
(It's strange that I'm not able to load any .dxf-files, even with that patch, as the option doesn't show up. After deleting the dependencies for dxf_input.py and inkex.py out of dxf_input.inx it works fine... This happens only under 0.46, the Inkscape-Nighlty doesn't have that problem)

Hello Chris,
    thanks for the testing, I will try to come up with a new version this weekend, it appears that Ubuntu is doing something different than Windows.
    I should mention that the .inx files between 0.46 stable and 0.46 development version are incompatible, so if you used the wrong one, then the .dxf option will not even appear on the menu. The .py files should be compatible between 0.46 and 0.46 devel versions.

I've got some good and some bad news:

The good one:
I figured out where the problem was: a wrong way of specifying the namespace was used
=> the fixed version is attached (I don't have rights to update the SVN, so please do it for me)

The bad one:
The dxf-import of my file looks realy bad :(

I'm tring to improve it now, but I'm neither a Phython nor a SVG expert. And I don't have any experience with the internals of a dxf-file or Inkscape...

The attached new version has a few improvements:

- bug fix: stop scanning as soon as a new entity (i.e. line[0]==0) arrives.
- bug fix: don't display some formatation in the strings (like \S or \W). A better solution would be to parse and format the string accordingly
- basic implementation of the HATCH entity

To make me happy two things are missing at the moment:
- the HATCH entity should display the partterns
- the DIMENSION entity isn't supported yet
And additionally I'd like to have the DXF scaled correctly. Scaling it to fit a A4 page looses the scale (e.g. the DXF file I'm using has a scale of 1:50 for an A1 paper IIRC)

Anyway: even the current implementation is good enough to add it on the next inkscape release.

It's me again

for this version I've added support for the DIMENSION

Still missing/prolematic:
- the lines are far too thick on my example file
- the automatic scaling to an A4 paper (that's probably also causing the point above)
- the HATCH should support patterns

Hello Chris,
    Thank you so much for your contributions to this extension! Both the HATCH and DIMENSION entities look as though they should be valuable additions to the library.
    I will start working on the implementation of these features this weekend, and will post a new result when it is done. I will also investigate the line thickness at the same time.

Hi Chris and Alvin

The newest dxf_input_py is giving me troubles.

I have attached several files for these comments. Both the results in svg and the raw file in dxf.

I have given them the date of the dwf_input.py file which you uploaded.

When I open the attached dxf file with the extention of Alvin from the 1. of february I get a nice file with layers and lines coloured with the respective colour i chosed in my Cad-Software.

When I apply the dxf_input.py from Chris from the 21. february I get a black coloured drawing with some "funny" black hatches. The layers are not imported. The dxf file consist of polylines, lines, mtext, and a solid hatch in greyscale.

I have also attached the dxf-file I used for the test.

I am not aware of what is causing me the trouble, the program does not come up with any errors or so.

Any ideas?

-----
Regarding the automatic scale to an a4. I think it came in when Alvin started to post one of the first *.py files, on my request, anyways...
When I draw in Cad, it is in scale 1:1 . Then when I print it with a pdf-printer (pdfforge.org) I make the scaling for a "viewport" in lets say a A1 page. I have been using Illustrator a lot, and when you import dxf/dwg files there it ask you how you would like to scale the imported drawing.
Question:
Is this difficult to implement? As I earlier said to Alvin, I am not capable of scripting, but hope by testing your good work, I can contribute to the extention :-)

Sorry for the long post,

Best regards,

/Mads

hello Mads,
thanks for the feedback, I'm working on a solution, but it may take a few weeks because I am somewhat overextended at the moment with other things.
   I'll post a new result here as soon as it is ready, and in the meantime probably suggest using the version from Feb 1.

Hi Alvin

No hurry, for now the extention from the 1. of February working fine for my needs,

Interesting to see, for me as a new participator in the Open Source development, that other people are starting to script on your files.

Best regards,

/mads

Hi Mads,

to make a quick first implementation for the HATCH feature I made it's pattern solid black. This ist causing the big black areas. You can easily select the polyline and give it a different pattern (e.g. gray).

The hatch shouldn't have such a irregular shape though...

PS: This script is a very typical example for Open Source development: I was just scratching my itch...

So, a new version from me (I hope, Alvin, you can easily merge the differences with your working copy):

Changes:
- implemented support for hatches that contain different areas (fixes the import of Mads file)
- support unicode characters embedded in text
- support MTEXT with more that 250 characters
- support DIMENSION with aditional text
- basic support for dotted lines

Still missing:
- the style of the HATCH ist constantly black
- the thicknes of the lines is sometimes wrong
- the scale is still broken as it is just scaled to A4 paper
- I've got a DXF file where some stuff doesn't get imported yet - I'll look into that issue next. Perhaps I'll add support for GROUPS at the same time

Bugs:
I don't know what's causing it, but after reading a DXF file Inkscape-Develop crashes as soon as I hit Shift-Ctrl-F :( It might also happen with other content, but as I don't have any at the moment I can't test it.

If the crash happens with latest svn, please file a separate bug,
attaching the svg file that causes it and detailed steps

Hi bbyak,

that happens with the current most file from https://launchpad.net/~inkscape-nightly/+archive/ppa (i.e. inkscape-devel - 0.46+devel~nightly8.10-7213-1 with the date 02.02.09).

So I guess it's not the latest SVN. But I don't have the resources to build inkscape from scratch, so I have to stay with those version.

Although getting a bit OT here: is there a reason the "nightly build" doesn't build nightly? And is there a different source to get a more recent version?

I've filed the constant crashing by opening fill and stroke as bug https://bugs.launchpad.net/inkscape/+bug/342755

In my tradition :) of releasing often, I've got a new version:

- the trigger for the inkscape crash I've observed was removed (the bug 342755 still exists, though)
- support for BLOCKS and INSERT
- switched the loaded page to display units as mm

Still missing:
- the style of the HATCH ist constantly black
- the thicknes of the lines is sometimes wrong
- the scale is still broken as it is just scaled to A4 paper
- I've got a DXF file where some stuff still doesn't get imported. Most got fixed by the BLOCK implementation, so I'm investigating the rest now.

Hello Chris,
    Thanks for the feedback. Sorry for the delay in responding, I was away on a business trip and am just getting myself re-organized.
    The changes necessary for the HATCH support are almost complete and then I will start on the DIMENSION support.
    Just a quick comment on the support for BLOCKS and INSERT. So far it has been possible to avoid the support of BLOCKS by using the QCad procedure of exploding BLOCKS, which I guess is also possible in AutoCAD as well (see comment 10 above). As a general rule of thumb, I don't think this script should support features like interpreting or rendering BLOCKS if these features can be easily implemented in AutoCAD or QCad.

Hi Alvin, great to see you back!

As I did only touch the HATCH a little bit(*), a diff should easily help to merge the versions.

As I need to import existing DXF files it's important to import them as they are. Using a different export method is no option, as I have neither the source file nor the program used to export them... Anyway, the BLOCK and INSERT is working quite nicely now :)

BTW: my working copy has inital support to scale the DXF to a power of 10 and still fill a A4 paper as much as possible. As a DXF doesn't contain the size it's supposed to fill, it would be great to have a option dialog during opening the file to let the user specify the page size. Is something like that possible?

CU,
Chris,
who's now able to nearly perfectly load all different DXFs he's got...

(*): I've added support for hatches that contain different parts (Mads' file is using that). I'm also ignoring the points that are seeding the flood fill for the different parts of the hatch now. Support for patterns is still missing :(

Hi Chris and Alvin

I have tested the latest import file, it is looking good,

But,

The layers are not rendered as they did earlier, but it seems that the script groups the objects according to the layers specs. in the dxf-file.

Good work,

Mads

, Chris do you also use Qcad for the export to dxf? I am using bricscad for Cad drawing, a much simpler (and cheaper) program that fullfill all my needs as a professional planner.

Mads Boserup Lauritsen schrieb:
> , Chris do you also use Qcad for the export to dxf? I am using bricscad
> for Cad drawing, a much simpler (and cheaper) program that fullfill all
> my needs as a professional planner.

No, I'm not generating any DXF files my self, I'm just loading those
from my architect and the guy who's planning my electrical installation.
That's also the reason why I need to load the files as they are.

- attached is a version that supports the HATCH entity, and I think it incorporates most of the suggestions made up to Feb 20.
- I will work on the DIMENSION entity next week
- this has been committed to svn rev 20910

Hi Alvin,

I just tried your version. To make it run I needed to change two lines:

********
195c195
< a = math.atan(ym/xm)
---
> a = math.atan2(ym,xm)
251c251
< name = line[1]
---
> name = unicode(line[1], "iso-8859-1")
********

Apart from that it's nice that the color in the HATCH is working now (patterns are still missing...).

For my files the last version I had posted is working much better though (but that was to be expected as your version was using the version of Feb 20). Probably the best solution would be to just use the export_HATCH from your latest file to replace my version and use the rest of my latest file (the diff above is already included in that file)

Hello Chris, thanks for the feedback.
- attached is a version that incorporates support for DIMENSION
- this has been committed to rev 20960

Hi Alvin,

that version looks great.

But I've still attached my latest version. It contains additional to my version from the 14.03.:
- Alvin's HATCH code
- addition to the DIMENSION stuff (still based on my code) that takes care of the text size
- much better handling of dashed lines (i.e. taking care of scale now)

Additional to your code my still supports:
- BLOCK and INSERT (which is necessary for a DXF file that's important for me)
- probably a few minor things

=> now we just need to join both versions and everything should be fine :)
(except that the HATCH should support patterns...)

To avoid duplicate development: who should do that task? You or me?

Hello Chris,
    My immediate plan, for the next month or so, is that I would like to implement the line style as you have done, and I would also like to introduce a new (optional) input parameter to specify the overall size of the entire image. While I am doing that, I will look at the issue of BLOCK and INSERT usage. I am not a big fan of implementing this feature because it is kind of like re-inventing the wheel. It has already been done by other people, for example, QCad, which is free. I guess my question is, do you have any examples of the use of BLOCKS, that is a simple example where it is easy to see what is going on?
    Other than that, my long term plan is that I would like to support this extension as much as I can until the release of Inkscape 0.47, at which time I think I would rather have someone else do it.

Hi Alvin,

that sounds good. Especially the papersize feature would be great (together with a restriced scaling of the DXF data, so that scales like 1:100 are preserved)

Implementing BLOCK + INSERT isn't reinventing the wheel, it's just supporting an important aspect of the DXF file format. I'll send you my DXF file by private mail so that you have an example to work with. It's not small, but the BLOCK stuff isn't that complicated on the other hand so you sould get started easily (especially as you've got my version to look at as a reference).

Hi Chris and Alvin

If I can be at any help, according to the block aspect please let me know.

I do not know what the "INSERT" command is, but regarding the blocks, I can produce any type you need to test... :-)

hth,

/mads

ps. I tried to import a 3d dxf file with the script.. I did not work, but maybe that would be a future job that the script automaticly assets all z-coordinats = 0. Not that I need it, just a thougth :-)

Hi Mads,

if you are defining a BLOCK it won't show up by itself. You need an
INSERT to put its content into the drawing. You can also use multiple
INSERTs to include the same BLOCK multiple times.

(at least that's what I think it is, as I only have the poor DXF
documentation that's available online...)

Hi Guys I also ran into a problem with some blocks, it seems they don't import at all, so what I did was explode them in my original dxf in my cad program, after that, no issue, they imported fine. I use Intellicad just so you know.
TNX Ryan

   good point, if the option to explode blocks is available to you, then I would definitely recommend using it.

   I just committed a new version of the routine to svn rev 21180. This has support for most of the changes discussed above: linestyles, BLOCK/INSERT, and an option to either have the image scaled automatically to size A4 or choose a manual scale factor.

   I don't anticipate making any more changes before the release of Inkscape 0.47, unless something unexpected comes up.

Hi Alvin and Chris

As I am new in the aspect of participating in the development, I hope you can live with my, maybe, stupid questions...

What is the "svn rev"... I searched both the forum and Google, but I cannot find the "svn rev 21180" anywhere.

As Alvin has not comitted a dxt_input.py in this thread I can not check if your scripting is working.

I just tried Chris' file from the 2009-03-22, and this py-file makes all lines black, and has only one layer.

I have read that the Inkscape team is launching the 0.47 in June, so if I by any mean can be at help for extensive testing please let me know.

Best regards,

Mads

    sorry about that, I was taking a shortcut. All of the original source code for these extensions can be found at :
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/
    I'm attaching the code for the dxf_input here as well, and you'll need to rename these files to remove the 47 from the name.

the .py file should be usable as it is. But the .inx file is new and you may need to modify it. If you are running a development version of Inkscape, you can use it directly, if you are running Inkscape 0.46 stable version then replace the first two lines :
<?xml version="1.0" encoding="UTF-8"?>
<inkscape-extension xmlns="http://www.inkscape.org/namespace/inkscape/extension">

with the single line :
<inkscape-extension>

hth,
Alvin

Hi Guys,

dxf_input.py from svn work quite well, I just came across a DXF file with some non-ascii text, encoded as
\U+nnnn (4 digit hex of the unicode value). The attached patch (against svn rev 21247) fixes that.
I guess there are more elegant ways of doing it.

Regards,

Marcel

Hello Marcel,
    Thanks for the patch!
    Could you also attach the .dxf file for testing purposes?

Thanks,
Alvin

patch tested and committed to svn rev 21274

The attached dxf file doesn't import properly in Inkscape 0.46 on Windows. It is exported from Agilent ADS.
I'm using the dxf_input version posted 23/4.

thanks for the feedback, it looks as though the problem is being caused by the large values of the drawing boundaries :
$EXTMAX = -100000000000000000000.0
$EXTMIN = 100000000000000000000.0

I will try to issue a fix for this within the next day or two.

- a fix for this has been committed to svn rev 21294
- the latest version is attached here, it will need to be renamed to dxf_input.py
- in this version, if you 'uncheck' the automatic scaling option then the $EXTMIN and $EXTMAX parameters are ignored completely, and the file will load, use a manual scale factor of about 0.1 or so.

hth,
Alvin

That worked perfectly. Thank you.

There is an another problem with dxf import routine. Try to import attached dxf. Every time I got following message:

Traceback (most recent call last):

  File "C:\Users\MOBY\AppData\Local\inkscape\share\extensions\dxf_input.py", line 407, in <module>

    entities[entity]()

  File "C:\Users\MOBY\AppData\Local\inkscape\share\extensions\dxf_input.py", line 190, in export_HATCH

    path += 'L %f,%f ' % (scale*(vals[groups['11']][i11] - xmin), -scale*(vals[groups['21']][i11] - ymax))

IndexError: list index out of range

The DXF file was produced with AutoCad 2009, and saved as a AutoCad 20007 DXF

    the problem was probably caused by the fact that the dxf file contains a pattern effect used in a HATCH element, while the current routine supports only solid hatches, not patterns. However, apart from that, there were BLOCKS in the file. So I loaded the file into QCad, and used the menu procedure Block | Explode to process the blocks and then re-saved the file. The resulting file loaded into Inkscape, attached here.
    I would recommend using the explode block routine either in AutoCAD or in QCad, whenever possible.

I've exploded blocks and drawn hatch (not associated) once again and then exported to DXF. There wasn't any problem importing the file to Inkscape this time but I've noticed some deficiencies. Those deficiencies are described in attached SVG. I am also attaching original DXF and PDF for comparison. I hope it will be useful for further developing of this routine.

thanks for the feedback, I'll put this drawing onto my list of things to do and start pecking away at it, a bit at a time.

Alvin

Hi Alvin (and others)

I have been struckling with the import command, as it kept deleting the layers from my dxf-files. But then I read through the whole thread and found that you at your comment the 1. of February explains, that layered dxf-files only will be imported with layers if they are "opened" and not imported. https://bugs.launchpad.net/inkscape/+bug/293940/comments/29

What I am saying / proposing is:

Should there be written a "manual" for your routine of how to use it and so fort? Do you need help to do this, or how does this work in general for the routines of Inkscape?

I have attached the original dxf-file and the two different svg-results. One imported and one opened, if someone needs and example of the above described.

Please let me know if I can be at any help before the 0.47 release,

Best regards

Mads

ps. And once again, thx for your scripting - it is a great tool :-)

    yes, unfortunately, you are right, the layer information gets lost on a File | Import, it gets used only on a File | Open operation. I think part of the problem is that there is a potential conflict between different definitions of the same layer if you import multiple objects into the same drawing and each object has its own unique definition of layers.
    with respect to documentaion, there is a wiki page at
http://wiki.inkscape.org/wiki/index.php/TutorialsAndHelp
but I am not familiar with how to use it. The good news is that this can be done at any time, independently of the release of 0.47. Also, if there is a very specific issue that you think is important, you can issue a bug report and put a tag 'dxf' on the report using the link that says 'Update Description / Tags'. This will make it very easy for others to find this report if they are searching for it.
   on the subject of documentation, there is a new feature that I forgot to mention. The scale factor actually used in loading the .dxf file is now stored in the svg document. This is useful mostly in the case where you are using automatic scaling. It is given in a <desc> tag which is viewable in the XML editor and looks like this :
  <desc
     id="desc14">C:\WINDOWS\Temp\1_most_na_soci_mapa_no_blocks.dxf - scale = 0.055106</desc>
    In the case of manual scaling this will be identical to what you specified when loading the file. Also, as far as I know, this <desc> tag will be viewable only on a File | Load, not a File | Import.

I have another file which isn't imported properly using the import script from 7/5 and Inkscape 0.46 on Windows. It should fit on an A4 page with scaling 1:1.

the import routine assumes that the scale of the original drawing is in units of mm. In the attached drawing it looks as if the scale is probably in units of microns, not mm. If you use a scale factor of 0.001 in the import dialog then the imported drawing will have a reasonable size.