[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Converting FrameMaker files to MS-Weird

Forget the Frame-to-Weird filter that comes with FrameMaker. It's worthless.

AVAILABLE THIRD-PARTY TOOLS
The most robust software that does this (as well as conversions to many
other formats) is Blueberry's Filtrix product. Their website is
www.blueberry.com. I believe they have a downloadable demo version available
on their site.

Another possibility is Omni Systems' (www.omsys.com) mif2rtf filter. They
also offer a demo version. To use mif2rtf, you first save the Frame document
in the MIF format, then run it through mif2rtf to produce RTF, then open the
RTF document in Weird. Since RTF doesn't preserve the graphics, this product
only works if all graphics in the Frame document are imported by reference.
After opening the resulting RTF file in Weird, you must re-import the
graphics (I'm not sure what it does, if anything, with FrameMaker native
graphics and equations).

EXPECTATIONS
There is no such thing as a clean, 100%-accurate, conversion to or from
MS-Weird. No matter which product you use, you will almost certainly find it
necessary to do post-conversion clean-up, the magnitude of which will depend
upon many factors, some of which are unpredictable. Conversion of special
characters (e.g., those with ANSI numbers above 126) may be iffy, since
FrameMaker uses the MAC character set (plus the Symbol and Zapf Dingbat
fonts for some characters), and Weird uses the Windows ANSI character set
and WingDingz.
 
FM+SGML CAN SOLVE MOST GRAPHIC CONVERSION PROBLEMS
Graphic compatibility is often a problem when converting Frame documents to
another DTP. One of the great advantages of having FrameMaker+SGML
(hereafter called FM+SGML) rather than FrameMaker is that FM+SGML has the
capability to export native FrameMaker graphics and equations, as well as
imported-by-reference graphics, in almost any format you desire. Even if you
don't create structured documents, this capability alone can be worth the
added cost of FM+SGML (you can upgrade a FrameMaker license to FM+SGML for a
price below $1000.00). There are also other benefits (FM+SGML is more stable). 

I've set up an FM+SGML graphic conversion applictation for this purpose that
includes a very simple DTD/EDD, read/write rules, and a template. The
purpose of this application is to convert any graphic format(including
native FrameMaker graphics and native FrameMaker equations) in my
unstructured FrameMaker documents to formats that are compatible with the
target system.

My graphic conversion EDD/DTD defines a separate graphic element for each
desired conversion type (e.g., BMP/DIB to TIFF/CCITG4, FrameMaker native
graphic format to CGM/WMF/GIF/JPEG, any imported graphic format to
CGM/WMF/GIF/JPEG, native equation to CGM/WMF/GIF/JPEG, etc.). 

First, I copy each graphic or equation (including its anchored frame) from
the unstructured FrameMaker document into a structured document that uses
the graphic conversion application's EDD, applying to each such copied
graphic or equation the graphic or equation element that produces the
desired conversion. Then, I export the resulting structured document to
SGML. This action exports each included graphic as a separate file having
the specified graphic format.

I then throw away the resulting SGML document instance (it serves no
purpose), leaving only the exported graphics. Next, in a copy of the
original unstructured FrameMaker document, I replace the original graphics
with the imported-by-reference graphics produced by FM+SGML. Now, each
graphic and equation object is guaranteed to be compatible with the formats
acceptable to the target DTP (or SGML/HTML/XML).  

EVALUATION PROCEDURE
Before choosing a product to do conversions to MS-Weird, I recommend the
following procedure:

1. Create a FrameMaker test file containing instances of each problematic
object type you use in your FrameMaker documents. The document should
include the following (as they are applicable to your FrameMaker documents):

        a. Representative graphics (native FrameMaker and imported
           graphics) for all the graphic formats you use.

        b. Complex tables with straddles, header and footer rows, etc.

        c. Footnotes (both table and text)

        d. Special characters with ANSI numbers above 126, including
           those which require the Symbol font

        e. Cross-references

        f. Index markers

        g. Running header/footer markers

        h. Variables

        i. Paragraphs that specify a reference frame above or below

        j. Paragraphs containing strings with tagged character formats

        k. Multi-column page layouts, with paragraphs, tables,
           and graphics that span columns, inter-mixed with some which
           don't span columns

        l. Page layouts that have sidehead columns

        m. Page layouts that have running header/footers that use
           variables

        n. Paragraphs, and strings within paragraphs, that use unusual
           fonts (e.g., Zapf Dingbats, Symbol, subscript, superscript)

        o. Paragraphs, figure captions, table captions, etc. that have
           autonumbering formats (including bullets and other prefixes)

        p. Native FrameMaker equations.

        q. Put enough filler stuff in the document to give it a
           significant size, so you can realistically evaluate
           the time it takes for each product to perform the
           conversion when it is stressed by the large size
           and the limits of available memory.

2. Convert the test document to MS-Weird or RTF using each of the demo
versions of the products I recommended above, plus any others you find.
Record the time it takes each product to perform the conversion, plus the
time it takes to open the converted document in MS-Weird.

3. Open each MS-Weird document produced in step 2, and thoroughly evaluate
and grade the conversion accuracy, and the amount of post-conversion
clean-up work that is required to make the Weird document complete and
acceptable. Record each type of anomaly produced by each conversion.

4. Based on the evaluation above, determine whether any of the products you
tested can produce an MS-Weird document in which both the conversion time
and the required amount of post-conversion clean-up labor are within
acceptable limits.

5. There are two possible outcomes from step 4:

        a. Give up the whole idea as unfeasible,

                OR

        b. Buy the product that requires the least amount of
           conversion time/post-conversion clean-up time, recognizing
           that each of the anomalies discovered in step 3 will 
           have to be fixed in each and every document you convert.

The same process described above can also be used for determining the
feasibility of conversion in the other direction--MS-Weird to FrameMaker.
The only differences are that the test file created in step 1 is an MS-Weird
document rather than a FrameMaker document, the conversion tools used in
step 2 convert in the opposite direction, and steps 3 and 4 are performed on
the resulting FrameMaker documents.

Dan Emory
Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design
and Database Publishing Specialists

Voice/Fax: 949-722-8971
E-Mail: danemory@primenet.com
10044 Adams Ave. #208
Huntington Beach, CA 92646


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **