forums.silverfrost.com

[wahorger]

I discovered a library of routines that can create DXF files for AutoCAD (R) Version LT2000. After struggling with having to learn about DXF file structures and interactions between sections of the DXF (information for which is buried in obscure documents), I was able to get it to work.

Turns out, knowing HOW to use AutoCAD does not actually help in creating a file from scratch.....

If anyone has an interested, I can share a link to my DropBox.

[LitusSaxonicum]

Bill,

That’s interesting, and potentially very useful to the appropriate people.

There seems to me to be a lot of issues with the use of proprietary software data formats. In my line of business, such as it is, I would find it very useful to be able to read geometry from an AutoCAD data file but that I would have less use in writing to such a file. Basically, the point would be that a user could use AutoCAD to prepare shape information to input to my programs.
There are several issues associated with proprietary software data formats not least that almost every release of that proprietary software usually involves changes to the data format. Looking at the AutoCAD website I see that the current release supports a number of older data formats, but only going back so far, and very clearly earlier releases don’t support writing data in the newer formats.

The situation is similar, but somewhat different, with one of my favourite programs CorelDRAW! Here, the boot would be on the other foot, in that I should very much like to be able to write my output in a CorelDRAW! CDR format so that I could use the graphics software to enhance my computer-generated pictures. However, the version related file format changes impinge on the usefulness of such an ability because from time to time Corel stop supporting the older formats.

Some decades ago I had a quick look at the then AutoCAD file format, and it looked to me like something that one might write from a Fortran program, but reading it could possibly be a nightmare because of all the extraneous information that the file contained. I have very little doubt that in the decades since I looked the problem for me has probably got worse.

Eddie

[wahorger]

Eddie,

I appreciate your comments. Because of AutoDesk's size in the market, they are here to stay for many applications. There are also competing file formats that offer better flexibility and performance, but are not so widespread.

I found an interesting note about DXF file on the Library of Congress website that deals with data archiving of digital content. They were not ecstatic about DXF, noting that AutoDesk keeps a lot of implementation details secret (i.e. if you use feature "A", then you must provide information in table "B" and in this format, and if you don't, I'll just crash the program due to this incompatibility). If you want an example, look at generating a SOLID (4-sided figure). For example, for a simple rectangle, you'd define points 1,2,3,4 going either CW or CCW. Not AutoCAD! You have to give the routine in the sequence 1,2,4,3. This is documented, but only in some places. The on-line documentation I've seen from AutoDesk does not tell you this!

At least for DXF files, AutoDesk has maintained the ability to read the older formats back into the mid-1990's. Writing something that "old" is problematic .

I spent around 150 hours over the last 5 weeks delving into DXF file formats, downloading and installing multiple tools to use as verification aids, and visiting websites. I finally found all the information that allowed me to do what I wish to do, leaving some potential features untested. For a later time, perhaps.

The routines that perform the lowest level I/O (they both read AND write DXF) are written in "C++". It is fortunate and a blessing that SilverFrost can use these routines via a DLL.

BTW, I tried to compile these DXF libraries with SCC. Unfortunately, there are a few missing "include" files and it was going to delay my implementation to try to recreate them from other sources. So, I went the DLL route, using the "gcc" compiler and CodeLite for the IDE.

I have a number of "C" and "C++" based DLL's that I use, as well as some big blocks of "C" and "C++" that are directly linked. While it is not trivial (sometimes) to modify "C" to be properly linked with FTN95, the work is worth the effort!

Bill