Structured FM - TOC and IX

[Lynne A. Price]

At 05:29 AM 7/24/2006, Ellen Lebelle wrote:
>And now, for the index, there are whitespaces that seem to interfere with
>the structure. The more pages there are references to, the more "untagged
>text" tags we get. Is there anyone out there who has dealt with this before?
>Or is thre a ready-made solution that we just don't know about?

Ellen,
   It is not difficult to structure an index and discard the white space 
between entries. Just make sure the generated white space has a unique 
character tag. For example, if the space that is causing problems is the 
one following a comma between successive page references for a single term, 
find the Separators paragraph on the index reference page. Define a 
character format (all properties can be set to As Is) and assign it to this 
space. In your conversion table, map the new character format to an element 
called something like Discard. Then, once you've structured the index do a 
global Find/Change to replace all Discard elements with nothing, i.e., to 
delete them.
   This simple process does add an extra step to structuring your index. 
You might consider using FrameScript or the FDK to create a new single 
command that updates your book, structures the table of contents and the 
index, and removes the extra space from the index.

At 08:54 AM 7/25/2006, Anderson, Eileen wrote:
>We handle this in a way similar to what Matt described. When building the 
>book, we wrap our unstructured TOC and cover page in a "TOC" and "Cover" 
>element, respectively. Inelegant, maybe, but it works for us!

At 12:35 AM 7/25/2006, Ellen Lebelle wrote:
>Just want to thank everyone for their answers. It appears we were trying to
>do something that just isn't worth the effort -overkill.

There is nothing inelegant about Eileen's solution, nor is what Ellen 
proposes necessarily overkill. Like everything else in a structured 
environment, treatment of generated files needs to be designed, and the 
design should reflect the intended use of the data. For example, if the 
individual index and contents entries are to be loaded into a database or 
compared to those from previous versions of a document, structuring the 
generated files may be quite appropriate.

Wrapping a generated file in a single element in FM allows them to appear 
as elements in the structure of a book and hence allows their position 
within the book to be controlled by the EDD (or DTD). Such elements can be 
saved to XML with or (using a read/write rule) without their contents. 
Without their contents, they mark the location in the entire document where 
the generated material belongs. The only reason to include the generated 
contents is if some process will use the information. In this case, it does 
make sense to structure the material.

         --Lynne




Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development, 
and training
lprice at txstruct.com           http://www.txstruct.com
voice/fax: (510) 583-1505     cell phone: (510) 421-2284