Martin Ley wrote: > I generally shy away from text insets, as they invariably barf on me in the > target document - I get a spurious paragraph at the end of the imported > inset which appears to be the same style (but with an asterisk) as the > first paragraph of the source text. > > This is a nightmare generally, and specifically if that initial paragraph > is a Head1 (for example) - I get a blank entry in my TOC. > > Over the years, I have tried various ways to get around this, and thought I > had discovered nirvana in the form of an old thread: > > http://www.freeframers.org/archive/00/msg01966.html
I looked at the first part of that post, and it contains a bit of misinformation and doesn't address the problem you were having at all, so I'm not sure how it seemed to work for a time. (Maybe just until you updated the text insets?) The misinformation: No "extra blank paragraph" is created (and certainly not "sometimes" as if it were a random event) when you import a text inset. This belief stems from a fundamental failure to understand how FM handles text insets. The "extra blank paragraph" is the empty paragraph in which your cursor was sitting when you imported the text inset. A text inset is something like an anchored frame or table. It sits in the flow as a zero-width object at the spot where you inserted it, i.e., the "container" paragraph. You can demonstrate this to yourself by putting the cursor at the end of the paragraph before the text inset and then pressing the right arrow key repeatedly. You'll see that a single key-press moves the cursor from just before the text inset to just after. Type some text after the inset, then triple-click somewhere in that text to select the entire paragraph. You'll see that the text inset, like the rest of the paragraph that contains it, is selected. Since the text inset source is a complete flow, it necessarily ends with a paragraph end. So the "extra" space is the result of two paragraph ends in a row: the end of the last paragraph in the text inset source and the end of the empty container paragraph into which you inserted it. The run-in paragraph solution that post outlines is one way to eliminate the "extra" space. Another is to not insert the text into an empty paragraph; instead, insert it at the beginning of the text that should immediately follow the text inset. Doing this also solves your original problem, discussed below. The original problem: A long-standing FM bug causes the paragraph containing a text inset to inherit the format of the first paragraph in the text inset source _if_ the text inset sits adjacent to the pilcrow (end-of-paragraph symbol) of the container paragraph. This is similar/related) to the bug that causes a paragraph override if you apply a character tag adjacent to the pilcrow. The solution to both is simple: separate the text inset or char tag from the pilcrow with a space or something. I prefer putting text insets in their own empty paragraphs (instead of at the beginning of whatever follows), so I always insert a non-breaking space between the end of the text inset and the end of the container paragraph. A regular space would work, but I prefer having a visible symbol there as confirmation (I always work with View > Text Symbols on and strongly encourage doing). I also use a dedicated paragraph format as the container for text insets, with size and spacing that works for me (i.e., introduces "extra" space that I've planned for and can live with), so I don't mess with the run-in stuff. But that's a matter of personal preference. HTH! Richard G. Combs Senior Technical Writer Polycom, Inc. richardDOTcombs AT polycomDOTcom 303-223-5111 ------ rgcombs AT gmailDOTcom 303-903-6372 ------
