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.
Richard Combs is right -- variables are the way to go. Since you're using structured Maker, you could set up your template master pages to pick up values from attributes in each document's root element. When you use a shared file in a publication, you set the correct attr val, and Maker will pick it up in the master pages.
You could go a step further and write up a FrameMaker script to automate setting these attribute vals in all the files in a book. You could do this in a number of ways. For example, you could trap the Book Generate event, and post a dialog that asks for the values you want. Or you could have a magic ref page on the first file in the book and use that to cache the attr values -- automatically apply those when you generate the book.
I suppose you could just as easily do this with non-struct variables... Set up the variables in the first file in the book, and automatically import formats (variables only) from that file into all the other book components. Since you're using struct I prefer using attributes, but it's really academic at this point.
In any event, you're not necessarily modifying the shared files, per se. If you modify them at render time, just don't save the changes. Shoot, make the files read-only. Anyway, if you have a rendering process that corrects the variables or attributes for each publishing run, it doesn't matter if you accidentally save... No harm done.
cud
> We have lots of books to write, maintain, and update. Many sections are
> redundant from one book to another, so we want to single source some of these.
> For example, the book layout may be something like:
>
> Cover
> TOC
> Safety
> Intro
> Description
> Operation
> Maintenance
> Fluid Specs
> Torque Specs
> Contact
> Back page
>
>
> Sections (files) like Safety, Description, Fluid Specs, Torque Specs, and
> Contact can be shared among operator, maintenance, and service manuals
> (books). Some can be shared from model to model.
>
> What we want to do is have the FrameMaker book (not the individual files)
> contain the master page, but so far, I can't find anything that supports this
> in Structured. This is so the header on each page can go something like:
>
> T-800 Terminator Operator Manual
> T-800 Terminator Service Manual
> T-1000 Terminator Maintenance Manual
>
> and so on, as determined by the book.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
