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?
Darren, 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 chapter. 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 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