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.
Subject:RE: Word to Framemaker From:"Keith Hansen" <KRH -at- weiland-wfg -dot- com> To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Tue, 27 Feb 2007 09:19:18 -0600
I'm sending this message to both the entire list and to Fred...
Some time ago, Fred posted a very helpful message to the TECHWR list
(see below). It talked about converting Word docs to FrameMaker. Fred
noted that macros helped him automate the process. He wrote macros to
strip out the following from the Word docs:
* Word headers and footers
* Autonumbering and bullets, etc.
* In-line graphics
Fred also used a macro to convert all x-refs to plain text and marked
them with a named character format.
Can Fred (or anyone else) provide more details on the specifics of such
macros? How would I go about creating each of these?
Once the macros have been run, I assume the text imported into
FrameMaker is pretty close to plain text. So, my other question is:
* Once the text is imported into FrameMaker, what is the best way to
apply the new FrameMaker paragraph styles to the text? (Well, better
than manually applying styles to each paragraph in Frame?)
We have to convert an 800 page Word doc into FrameMaker. That's why I
ask...automating some of the process would certainly help.
Sent: Thursday, January 25, 2007 1:54 PM
Subject: RE: Word to Framemaker
The first point I would make is that the "WordPad-like text" is the
*real* content of your document. Everything else is really just
presentation, and is either background items (things like logos, titles,
and dates that appear in the headers and footers for page after page),
content that is derived programmatically from the *real* content (TOC,
running headers/footers that are derived from headings, index, the text
portion of cross- references), and purely presentational content that is
generated by the tool itself (page numbers, autonumbering, autotext,
bullets). Word basically munges all of these into a single layer
(particularly in Print Layout view), while FrameMaker separates the real
content from the formatting layer (the paragraph and character format
catalogs), from the background layer (master pages), and from the
derived and system-generated content (system variables, generated files.
(A structured authoring environment using XML or SGML goes even farther
in separating content from formatting and presentation, but that's
another whole discussion...)
In our group's migration from Word to FrameMaker, I was responsible for
converting dozens and dozens of documents, totalling >10K pages, and in
my experience the key to success was leaving behind as much of the
Word-specific presentational features as possible. Headers and footers
were already pre-built in my FrameMaker templates. Autonumbering and
bullets and autotext for notes and cautions were pre-built in my
FrameMaker templates, so I wrote Word macros to strip all that
formatting out of the Word docs. In FrameMaker we were going to insert
graphics by reference, so there was no point in trying to convert the
in-line graphics in the Word docs; a macro got rid of them
pre-conversion. In FrameMaker we were going to use a file-per-chapter
model rather than our mnolithic Word docs, so cross-references were
inevitably going to get broken; another Word macro converted all x-refs
to plain text and marked them with a named character format so that we
could find them and reconstruct them post- conversion. Index entry
fields in the text came across just fine (I don't know why the are not
doing so for you); all I had to do after conversion was add the
generated file to the FrameMaker book and click the Update Book button.
ToC, LoF, and LoT were similarly trivial to rebuild after conversion
using pre-formatted templates; it took less than 10 minutes per book to
completely reconstruct all the generated files. The slowest part of the
conversion and clean-up was dealing with tables, since Word and
FrameMaker have fundamentally different underlying models.
But Rick Quatro's wonderful TableCleaner plug-in takes a lot of the pain
out of with some really intelligent global operations.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-