TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I've done quite a bit of Interleaf-to-FrameMaker conversion for my clients.
I use both the workstation-based filter put out by Adobe (I haven't tried
the one in the Windows version of Frame 5.5; maybe it's just as god) and
Blueberry's Filtrix. All filters are terrible, but they're terrible in
different ways. For large projects, I:
* Alter the Interleaf source files to put them into a form that converts
more cleanly.
* Write filters (sed and awk scripts, mostly) to pre-massage the Inteleaf
ASCII files.
* Convert using both packages.
* Post-filter the converted output.
* Assemble the result, using text from one and tables and graphics from the
other. Equations don't convert, so I filter the source AGAIN by copying the
equations to their own file and printing it to a PostScript file, which I
then import. Some diagrams don't convert, either, for no apparent reason,
so they get the same treatment.
* Hand-tune the results.
While this sounds complicated (and it is; I have a 14-point checklist), it's
the only way to fly when converting thousands of pages of reference manuals,
which is the sort of conversion job that comes my way. The results are
pretty good and are very consistent, so later tweaking is straightforward.
Bringing in a large number of temps to do manual conversion gives very
inconsistent results. The structure tends to be wildly inconsistent and the
content tends to be damaged in random ways.
It's an lengthy, ugly, and expensive process, and I always advise my clients
to let the old documentation stay in its old format if they can. But for
long-lived products, this is generally not a possibility.
-- Robert
--
Robert Plamondon * High-Tech Technical Writing
36475 Norton Creek Road * Blodgett OR 97326
541-453-5841 * Fax: 541-453-4139 mailto:robert -at- plamondon -dot- com * http://www.pioneer.net/~robertp
