Re: Formatting Docs On-The-Fly

Subject: Re: Formatting Docs On-The-Fly
From: "CB Casper" <knowone -at- surfy -dot- net>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Thu, 15 Dec 2005 18:11:19 -0800

<< Is not such modifying the style on-the-fly such a wide-spread issue that structured Framemaker is bound to be of limited use? >>

Our processes are very rigid and only valid SGML
coming from FM can be accepted into our delivery
system. If it fails, it will not be accepted, so we
are in a situation where we have a hard stop as to
how creative we can get. Sure, we can get around some
of the limitations, as long as we can still get it
validated, the system won't care, and I've been known
to do that at times.

Our limitation is that we did some extensive mods to
FM for in-house use. As FM evolved, our costs for
changing our tools got to the point where it wasn't
cost effective to continue with FM. The experts who
could make the changes retired or went away, so we
were left hanging. We started with 5.0 on Unix,
included Windows on 5.5, then went to 6.0 when we
decided to migrate to XML, so no new dev is being done
to our FM tool.

We saw the opposite that you did. The tool limited
our ability to express what we needed to show to our
customers. We had no ability to change fonts, and
limited ability to use font effects to emphasize
particular words, so we learned how to use the given
elements to express ourselves to the users.

We are moving into Epic Arbotext XML, and the
structure in this environment is even tighter as we
are limited by the markup we have available to us via
the tools we will be using. Some teams have been
fully trained and are using XML, while others are in
the middle of training, such as my group.

We have been given an edict by the corporate folks to
have a single style for all of our documentation, and
since they will control the output transforms, they
can finally do so once all groups are on board.

While we can provide structure to our docs via the
markup language avilable, we will not be able to
control the actual presentation, which takes some of
the burden off of us, but it still leaves open those
situations where we need to violate the standards.

Hopefully by getting authors involved with the tools
at the development stage, which they did, we will have
all of the markups available that we need, or will
find something that suits us.

A simple example is a command to be entered into the
computer. We will have a <command> tag that we must
use whenever we show a command in the text.

This will result in a fixed-width font that will be
different than the surrounding text. This will also
result in the system being able to create a list of
all commands used in the document as a summary.

Forcing writers to use a rigid structure for writing
also results in being able to systematically go
through the docs and extract other information as a
direct result of using a stuctured markup language.
There are other benefits beyond just the resulting
document from a structure being applied to docs.


-- for Free Email <br> for Low Prices on Hotels, Books, and more.

Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today!

Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release.

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

Previous by Author: Re: Callouts in Graphics
Next by Author: Re: Callouts in Graphics
Previous by Thread: RE: Formatting Docs On-The-Fly
Next by Thread: RE: The resume grinder?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads