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
[EMAIL PROTECTED] http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
_______________________________________________
You are currently subscribed to Framers as [EMAIL PROTECTED]
Send list messages to [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [EMAIL PROTECTED] Visit
http://www.frameusers.com/ for more resources and info.
