Text inset (FM9)

[Combs, Richard]

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
------