Milton, Cynthia wrote: > I have a number of docs with text insets. When I do an update, an extra > carriage return is added at the end of the inset which duplicates the > paratag of the first line of the inset. The first paratag is a section > head with a page break, so this also is duplicated. The result is an > extra empty page which cannot be deleted as FM reckons it's part of the > inset.
This comes up every few months on the list. There is no "extra carriage return" being added. When you import a text inset, you're importing it _at the cursor location_. More than likely, that's in an empty body pgf. A text inset always "sits" in a pgf -- it has to, it's just another text object, like a char, xref, or marker. You can confirm this to yourself by putting the text cursor somewhere above the text inset and pressing the right arrow key repeatedly until the cursor moves past the text inset. Notice that a single keypress moves the cursor from before the text inset to after it -- to FM, it's just an object in the text flow, like a marker. The problem you're experiencing is the result of a long-standing bug. When a text inset sits at the end of the pgf that contains it, the container pgf takes on the format of the first pgf in the text inset. This is analogous to the related bug regarding char formats: when a char format extends all the way to the end of the pgf, it creates a pgf override. The solution in both cases is "don't do that." If you import text insets into empty pgfs, always put something between the text inset and the end of the pgf that contains it (I use a non-breaking space so there's a visible symbol, but anything will do). By all means, work with text symbols displayed so you can see the pilcrow at the end of a pgf, etc. HTH! Richard Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 ------ rgcombs AT gmailDOTcom 303-777-0436 ------