Re: Formatting Docs On-The-Fly

["CB Casper" <knowone -at- surfy -dot- net>]

<< 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.

CB


-- 
http://www.surfy.net for Free Email <br>  http://www.ergova.com 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! http://www.webworks.com/techwr-l

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. http://www.componentone.com/TECHWRL/DocToHelp2005

---
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 http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com

Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.