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