HELP! FM8.0 MIF Exported File Contains "old" text - why?

[intj57]

I am using FM 8.

I exported my fm documents to a MIF file.

Why are there "old" text and cross-references in there that you do not see when working in the *.fm doc uments and book?

Need answer ASAP!

[Bob_Niland]

Are you refering perhaps to MIF markups like:
<XRefSrcText `72317: OldPgfFmtName: Old Paragraph Content'>

Some auto-created Frame marker data structures include the paragraph format and content at the time of original marker and xref creation. This data is often never updated when the target format and/or content later change. It can hang around, mostly harmlessly, forever.

[intj57]

For example if I see a cross reference to a Figure for technical documentation I wrote years back, that was deleted from the document and I still see the Figure Title and it is old and shouldn't be there.

The figure text was not auto-created. Just the figure number was auto created.

My document is unstructured and we upgraded from FM7 to FM8 at one point.

I have to export my *.fm Files to *.MIF files so they are text and can be scanned before they go out to the customer.

[Bob_Niland]

For example if I see a cross reference to a Figure for technical documentation I wrote years back, that was deleted from the document and I still see the Figure Title and it is old and shouldn't be there.

Frame doesn't understand "shouldn't". The MIF markeup often contains the original text, which could be a prior revision, rough draft or informal placeholder text.

I have to export my *.fm Files to *.MIF files so they are text and can be scanned before they go out to the customer.

Then extra care is required.

As I said earlier: "It can hang around, mostly harmlessly, forever."

In a more sobering scenario, document metadata, like MIF markeups, can be subject to Discovery in lawsuits, and could become evidence in a criminal case.

Suppose you needed a cross-reference to some text not yet crafted, and at the target location used a placeholder paragraph saying:

"Client's hopelessly inadequate safety warning goes here."

Later you changed that to:
"To avoid oil platform self-destruct, be sure to ..."

Guess what's memorialized in the MIF?

_______

The above is not formal legal advice.

Barratries not included.

[intj57]

When you create a PDF out of the text you can visually see in the *.fm documents, does that extra memorialized "stuff" you see in the MIF files get put into the PDF somehow?

[Bob_Niland]

... does that extra memorialized "stuff" you see in the MIF files get put into the PDF somehow?

That, I am not sure about. My guess is generally, no.

If you create unsecured PDFs, it's easy enough to search them and find out, using an external tool (like Unix/Linux "grep"). Acrobat/Acroread search probably won't see it.

If there's a meta-risk, it might arise if you select "Create Named Destinations" or "Create Tagged PDF".

In this regard, Frame is probably much less troublesome than Word, which has meta-bitten any number of people in the butt (mostly lawyers). Word tends to retain all prior versions of the document, inside the document, easily found by any recipient of the .doc.

[Bob_Niland]

... I still see the Figure Title and it is old and shouldn't be there.

Although you might think it would be a nice idea if Frame regenerated all internally created markers during Update, there is at least one sound reason why it doesn't: conditional text.

In my present project, I generate two variants of the same manual for domestic and export. In many cases, either the leading term, if not an entire paragraph is conditional to locale A. Usually the leading term for locale B immediately follows the term A, or a para with condition B follows para A. But I want cross-references to be the same for both manuals, and I want to avoid having duplicate conditional Xrefs. So there are often two Heading2's at the same place, but only one marker, used by "See Heading2 on page" Xrefs all over the book.

When a cross reference to a conditional paragraph is created, Frame automatically inserts a marker at the start of para, and that marker automatically gets the condition code of the first letter of the first word. I have to reset these to unconditional, but because Frame never revists the marker definition, they stay unconditional, even after Update Book.

If Frame were regenerating such markers, odds are it would re-apply the CC, thus causing unresolved Xrefs in one or both versions of the book.

Another reason to not regenerate is Xrefs from other documents. There are probably more reasons.

So even if you submit this as an enhancement request, chances are it won't get implemented. It would have to be a new Document Properties option, and off by default, because simply changing the behavior would break many documents upon next Update.