Washing OrCAD-based DXF files for use in Frame docs

[George Mena <George -dot- Mena -at- ESSTECH -dot- COM>]

I originally sent this to a single user on this list.  After I did it, I
thought that this was good info to pass on to everyone else in the list,
so here goes:

As many of you know, DXF files can be imported into Frame.  What you may
*not* know, however, is that you need to send a DXF file through both a
graphics converter and a CAD program before you get the DXF file to
adequately behave itself when it's being imported into Frame.  This is
especially true if you ask your engineers for a DXF file from their
OrCAD originals.

* If you dump the OrCAD DXF file directly into Frame, only part of the
DXF file will be visible because the drawing extents have not been
readjusted to obey the graphic frame's boundaries in your FrameMaker
document.  This results in the middle of the OrCAD file appearing, but
not its periphery.  If you're importing a DXF file of a schematic for an
audio/modem card design, for example, you'll get the DSP pinouts but not
the pathways to the AC'97 codec or to your Caller ID features, which are
more likely to be on the periphery of the drawing.

* While you can use Select All in Frame and scale down, you'll find that
it's easier to open the DXF graphic in Graphics File Converter and
re-save the DXF file with the AutoCAD version of the DXF import/export
filter.  Doing this lets you replace the OrCAD tag in the DXF file
header with the AutoCAD tag, making the DXF file behave itself during
import into the Frame document.  Additionally, the DXF file from OrCAD
can now be opened in AutoCAD, which can also let you make last-minute
changes if your internal customers ask you to make them and re-export
new DXFs with the "latest and greatest" version of the DXF engine in
AutoCAD (OrCAD, Imsi [the makers of Graphics Converter] and other
software publishers are allowed access only to the *previous* version of
the DXF engine controlled by Autodesk.).

[Gripe on Imsi:  the reason their software crashes on the third file is
partly because of Autodesk's control of the DXF engine, but also partly
because the folks at Imsi didn't recompile Version 1.0 of GCG into
Version 3.0, the current standard.  It's a 16-bit program modified to
work in a 32-bit environment like Win95. :P  I've not seen a Version 2.0
of this product, nor have I seen notes on Version 2.0 at
http://www.imsisoft.com, which leads me to think Version 2.0 has never
existed.  But a guy''s got to use *something.*]

* It's important to note (A) that if you *don't* wash the OrCAD DXF
through Graphics Converter Gold, it *won't* open up in AutoCAD at all.
If you try, AutoCAD will return the error message "Error in APPID line
248 -- drawing discarded" and not open the DXF file at all; and (B)
that you limit your DXF graphics-washing sessions in Graphics Converter
to *two* files per session and reboot regularly to avoid Fatal
Exceptions crashing your Win95/WinNT environment.  This also has the
added benefit of refreshing your system memory (RAM) so you can continue
to march towards your deadline safely.

* Finally, always make sure that you ask your engineers to remove all
the line breaks in the OrCAD file before exporting it into DXF format.
Otherwise, you have to use something like Prolix (a freeware
programmer's text editor) to parse the header string and physically
remove the line breaks in the DXF code.  This is a tedious process
that's very hard on your eyes and very time consuming, because you want
to make sure you didn't miss a break somewhere in the string, which can
be 23,000 lines of code in length or more very easily.

George Mena
Technical Writing Consultant
George -dot- Mena -at- esstech -dot- com