1 person found this helpful
It looks like your text inset closes with an empty paragraph with the heading format.
First remove any unnecessary paragraph format from the text inset document.
Also: Make sure that you add a (non-breaking) space into the paragraph that receives the text inset and insert the external document before this space:
<text inset><non-breaking space>¶
I have seen teams using an even stricter approach: They defined a special 2pt line-height paragraph format that is used as first and last pgfs inside each text inset as well as being the pgf format used for the receiving paragraph. But this might be a bit over the top.
To reset your receiving paragraph format you might need to set the pgf fmt, then triple-click the pgf and reset any character formatting (select "Default ¶ Format" from the list of character formats) and then apply the pgf fmt again.
Thank you for your advice.
I do not understand what a non-breaking space is. Also, the inset ends with the regular 'body' paragraph format. I have opened a new document, did nothing to it, inserted the inset and imported the formats from another (correct) document. This works but only for a short time. After a while, the title format re-appears.
I have read up on the 'non breaking space' but how do I insert this in Frame? I have tried the character pallete and hex input both to no avail.
Use Ctrl+Space or Esc space h to insert a hard (non-breaking) space.
... insert a hard (non-breaking) space.
... in the receiving empty paragraph. I just ran into this for the first time yesterday.
The other solution (which is reported in another older thread), can be used where you are importing the inset with formatting:
Define the final paragraph, in the inset, to have Pagination property Run-In Head, no punc.
Coming back to daily FM after a couple of years away, I'm now getting back up to speed as well as getting to know FM10. I was sorry to discover that this "feature" is still alive and kicking, but thought I'd report back on how I overcame it :-}
I tried the two simple approaches (Run-in head for last paragraph in inset, non-breaking space after inset) and still had an unwanted, empty level two heading in the target document and the TOC.
I painstakingly implemented the over the top solution Michael helpfully mentions … the target document looked OK, but the TOC was still messed up.
Then a eureka moment … I examined the source file for the inset, and found that Format > Page layout > Pagination was set to Double sided. Changed that to single sided and voilà – perfect chapter, perfect TOC.
> .. even after deleting the inset I cannot change or delete the paragraph tag.
Just to wrap up this topic, the above is a reasonably common side effect of text insets, and there are no standard menus or dialogs for clearing it.
To unlock the tag:
- put some unique text nearby, say "xyzzy"
- save the [importing] file as MIF
- using a plaintext editor, find the paragraph using the unique string
- look for a <PgfLocked Yes>
- change the Yes to No
- save, re-open in FM, save as .fm
See <PgfLocked Yes> after text inset for further info.
Very interesting information! thanks.
Run-in head, no punctuation does the trick, indeed, and managing another style is a small price to pay; thanks for that! It also helps me conceptually, suggesting that you're bound to have two paragraph marks one after the other: one for the paragraph with the insertion point and one for the end of the insert itself.
Just out of curiosity, I checked the offending file in .mif while it was still showing the rogue or phantom paragraph: nothing was locked, anywhere. What would be doing, if it were there?
You write: "managing another style is a small price to pay"
Is this style for the final paragraph in the inset (not the receiving paragraph)?
Does it have both of these attributes:
- Run-in with no punctuation?
Now I look at it, the new style
:disclaimer_lastis only in the inset text – which obviously makes it easier to manage. The
:anchorstyle is the one I use for table anchors everywhere in the document set, with negative space before/space after values. All in all, it feels like a fairly "clean" way to deal with the problem.
Thanks. I will study this example.