
# from Matt Squires # on Saturday 27 August 2005 03:15 am:
I have posted the import files for dxf2svg conversion. I have tested on a variety of processors, OS's, and versions of g++. Not everything is imported from dxf, but it is a start.
Please package all of your files under one directory (the ./README in your zip unpacks above the rest of your tree.)
What files are you using for testing? Could you please post them? I get segfaults and hangs with several of mine. Seems lwpolylines in particular are a problem. If you're using qcad dxf's they don't (last I checked) have "closed" polylines -- instead of setting the "closed" flag, they just meet at a point (or was it that they do both?...)
Bulged polylines (lwpolyline entities with rounded corners) in particular seem to be a problem (probably because bulges are inlined to the point array.)
You also have a memory-limit issue. It looks like you're slurping the entire dxf into memory and building all of your data-structures before starting to work, which causes it to run up to 1.2GB and abort on some of my larger files. To get around this, you have to use a smaller-footprint strategy such as the one (involving seek()) in my CAD::DXF module.
There are also some issues with 3D entities. I haven't found any references to "normal" or codes 210,220,230 in your code. You should probably ignore entities with non-Z normal vectors (the spec calls them "extrusion direction") in converting to 2D.
Here's a summary of some of the files that I've tested. I'll put these in the uber-converter[1] repository[2] if you want to test them. The last one is 8+MB compressed, so I won't put that in the repo. Ping me off-list if you feel up to attacking the memory-limit issue.
3d_circs.dxf incorrect arc.dxf segfault bulged_lwpoly.dxf hang chckmir.dxf segfault chckcpy.dxf segfault example.dxf segfault polylines.dxf hang segs.dxf segfault viewtext.dxf segfault
circles2k2.dxf Abort
It looks like you have a lot to do to get done in time for SOC. I don't know if the inx format supports pipes, but even if it doesn't a simple wrapper would make the following uber-converter chain into what looks like one command.
cat file.dxf | dxf2rzp | rzp2svg > file.svg
A bit of hacking on the python rzp2svg would get you just as far *very quickly* without any of the aforementioned issues and would likely yield more long-term growth if inkscape doesn't mind the dependency.
--Eric
[1] http://scratchcomputing.com/projects/uber-converter/ [2] http://scratchcomputing.com/uc/trunk/