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: Frame -> HTML From:"Eric J. Ray" <ejray -at- raycomm -dot- com> To:Bill Burns <BillDB -at- ILE -dot- com> Date:Fri, 08 Oct 1999 08:23:22 -0600
Bill Burns wrote:
> > Webworks maps Body1 to "default" by default. What you say is perfectly
> > correct, but if you have the manuals I've been dealing with, what
> > Webworks produces is Garbage Out that *must* be edited. The development
> > effort to deal with whether Body1, etc. tags are in a doc, whether the
> > split of HTML files is at the correct spot, etc. is another edit cycle,
> > IMHO.
> >
> So don't edit the output; fix the source. This sounds as if all of the
> default mappings are being used, which suggests that the mapping phase of
> the setup was done cursorily. It takes minutes to remap all of the styles in
> a book. If the layout is basic, the setup is also simple. However, if you
> simply accept all of the default mappings and if you have loads and loads of
> overrides in the Frame files, you WILL have to clean it up. That's a problem
> with the source, not with the conversion tool.
And Bill's comment nails one of the really significant points about
doing anything but a one-time conversion. If you're doing a conversion
(from anything to anything, but we'll use Frame->HTML in this example),
that will ever be done again (including probably anything with WebWorks
Publisher), DO NOT EDIT OUTPUT FILES.
If you edit output files, rather than fixing source files or fixing
the conversion template, you're just guaranteeing that you'll have to
do the same fix EVERY time. It's helpful for me to think of writing
in Frame with the express intention of converting to HTML with
Wpublish as a programming-style process.
Source files (.java, .c, AND .fm, changable at will)
Compiler (javac, gcc, AND wpublish or wpbatch, changable to control how
output files are created)
Output files (.class, .o, AND .html or .gif, unchangable)
Why look at it this way? Because traditional output files are
unchangable without going through the whole process again. Because
output files are expendable--as long as you have the source files
and compiler, you can recreate the output files at will. Because
anything you do to output files will have to be redone after the
next build, which is a horrible waste of effort.
Programmers don't have the temptation
to tweak output files (because it can't be done), but it's easy to
succumb to the temptation of just one little tweak to .html
output files. That said, it's a BAD IDEA.