At 04:58 AM 7/7/2008, Butler, wrote:
>I'm considering generating the TOC to a separate file, then importing
>the TOC as a text inset.
>Any thoughts on this?

   Are your documents structured? As Yves pointed out, updating an 
unstructured book does not update the local tables of contents. The problem 
is that if you use the same paragraph tags in all chapters, then there's no 
way in an unstructured document to restrict a table of contents to only one 
   In a structured book, you can use context labels to distinguish entries 
for different chapters. You can therefore put the local TOCs into your 
book, remembering not to print them, and update them when you update the 
book. Or, you could have one book with the chapters and local TOCs that you 
use only for updating, and a second one without the local TOCs that you use 
for publishing.
   The technique is described in the following message which I sent to 
Framers a couple of years ago:

>   Since there's an ongoing thread on chapter TOCs, I thought I'd share an 
> idea I had recently. In a book with numerous chapters, it is a pain to 
> remember to generate the local TOC for each chapter. A minor tweak to the 
> EDD, and a slightly strained structure, allows me to build them in a 
> single book.
>   In particular, I've defined a choice attribute on the chapter element 
> that serves as a code name, with arbitrary values (say, flower names), 
> making sure that I've defined more values than there will ever be 
> chapters in an actual book. The EDD then assigns context labels for each 
> element that I want in the chapter TOC based on the possible values of 
> this attribute. For example, Section, Subsection, and Subsubsection might 
> each have context labels Daisy, Tulip, Rose, and so forth. If I use a 
> generic Section element that can be nested within itself, I might give it 
> context labels like Daisy1, Tulip1, Rose1 for the first level, Daisy2, 
> Tulip2, Rose2 for the second level, etc.
>   If I assign the code name Daisy to a particular chapter, I set up its 
> TOC to include only Section(Daisy), Subsection(Daisy), and so on. I've 
> used code names instead of numbers because I don't want to associate the 
> selection with the order of chapters in the book. With the code names, I 
> can reorder the chapters in the book, or add new ones in the middle 
> without the identification becoming confusing. I could have used a unique 
> ID instead of a choice attribute, but I wanted the EDD to list the values 
> used by the context rules that assign the context labels.
>Not very efficient--FM scans every file in the book to build the TOC for 
>each chapter, but it works.
>   In practice, I actually assigned all the context labels to the Title 
> element rather than the Section element. My Title element doesn't have an 
> ID attribute, but the Section element does. Thus, I can use the context 
> labels on the Title element to set up the chapter TOCs without having 
> them clutter up the cross-reference dialog box. I use context labels on 
> Section for cross-referencing.


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

Reply via email to