Known Participant

Question

FrameMaker loses formatting during crashes

Forum|Forum|15 years ago
April 1, 2011
18 replies
2568 views

I recently upgraded from FrameMaker 8 to 10, and I have noticed that Frame 10 has a charming habit of losing formatting when it crashes. So for example, if a paragraph tag is supposed to be bold, all text with that tag will no longer be bolded after the crash. The paragraphs are still tagged correctly, but I have to go back and apply the "Default Font" character tag to each paragraph with mangled formatting. It's incredibly aggravating, and I usually just revert to an older version of the document (and copy any new or changed material over), but obviously this is inefficent and will be error-prone in the long run. Just out of curiosity, has anyone seen this bad behavior?

I don't know if it matters, but I am using Windows XP Professional 32-bit, and all of my files were created in Frame 8.

This topic is closed to new replies. Start a new post to keep the conversation going.

A

Anonymous

rb3, some troubleshooting questions.

1. is the FM10 install on a new/different computer or was an O/S upgrade or Service Pack done to the system from when you were using FM8?

2. It would be interesting to examine the MIF file of a problem file, specifically at a section where the formatting has been lost. I'm wondering if there is any distinction to be found between the pre-existing formatting (e.g. from the MIF of a file that hadn't crashed) vs. that of the crashed file, specifically where the formerly good formatting is lost.

The best tool for looking at MIF is the excellent freebie MIFBrowse, by Graham Wideman, available here:

http://www.wideman-one.com/gw/tech/framemaker/index.htm

Even through it hasn't been updated for eons, it still works perfectly.

What I'm wondering is whether there might be some difference in the FM8 vs FM10 MIF codes. Or whether the crash is blasting the paragraph tags with some font override statements.

3. What fonts are you using in the problem docs? Specific fonts and type, TT, OT, PS? And what printer do you have set as the default for FrameMaker, do you use other excellent freebie SetPrint, from http://www.sundorne.com to control what printer FM sees as the default, independent of what the O/S has as the system default?

4. After you have a crash, do you reboot your system or just open FM again?

5. Can you look in the XP Control Panel for the Event Viewer, to see if there are any errors written from the crash.

6. Look at the FM console file, console.txt, usually located in the FM install directory in XP, to see whether there are any errors written there (if there is a chunk of hundreds of numbers don't post them on here, they're only intelligible for Adobe support, not us mere user forum folks)

EDIT:

7. What specifically are you doing when FM crashes, can you identify what actions lead up to the crash?

Sheila

Message was edited by: Sheila Carlisle

R

r0ybatt3Author

Known Participant

Thank you all for the responses.

Van, just to clarify, when this happens, Frame is actually not creating a .recover file. The file that is corrupted is the saved .fm file. I do daily backups to a source control system, so that's helpful, but of course it's not a perfect solution because those archives can be up to a day old.

Error7103, thanks for the tip about not reopening the .fm file and overwriting the .backup.fm -- I have been guilty of this. Next time this happens, I'll definitely copy everything before opening anything.

Sheila,

1. Frame 10 is installed on the same server as Frame 8 with the same OS and service pack.

2. I haven't looked at the MIF file yet -- I will try that. Thank for the tip on the freebie.

3. The fonts in question are Arial and Arial bold. The are TrueType fonts. I am user Distiller X.

4. I do not reboot after crashes. Should I?

5. I did not check the Event Viewer on any of the occasions when this happened. Looking now, I do see some Frame errors, including a few hanging errors, which has been another problem I've encountered since upgrading. Because I don't recall the exact times and days of the incidents, it is difficult to tell now which errors might be specifically linked to this, but next time I will look right away.

6. I've just searched my FrameMaker 10 folder, then my entire Adobe folder, and according to Windows there is no file with the word "Console" in the name except for 21console.jsx. In my Frame 8 folder, I do find several files whose names begin "FrameLog_date," which have contents similar to what you describe, but there are no current files like this -- none in my Frame 10 folder.

7. Because the crashes have happened unexpectedly, and they did not occur close together (ie., they've been spread out over a few weeks, not a few days), I don't have a perfect recollection of what I was doing prior to them happening. My general sense is that they're related to the creation of PDFs. Also, I know there was at least one occasion where FrameMaker was hanging for more than 20 minutes, and I ended the program. I realize that sounds like a bad thing to do, but the program was completely unresponsive and I didn't see an alternative.

Roy

Jeff_Coatsworth

Community Expert

Why have you got FM installed on a server? Not a normal procedure AFAIK.

Bob_Niland

Community Expert

... Frame 10 has a charming habit of losing formatting when it crashes.

Frame has always had that "feature".

The only thing that is usually safe to open after a crash is your previously saved .fm file, or a .backup file.

If Frame managed to create a .recover, open it separately, and only use it copy back the latest local edits.

Go no longer between saves than you care to re-create. Be advised that Frame can sometime crash DURING save. Check the timestamp on the .fm file in question to see if it is now questionable.

I primarily use FM7.1 on Unix, and it crashes a lot, due apparently to some degenerate intersection of our odd page layout and massively networked document files.

Sometimes I get a .recover, usually not.
Sometimes I get a crash message on the console (usually 7103).
Sometimes the crash crashes, so we routinely have a non-writeable "core" directory in every document dir, to prevent time-consuming creation of useless huge core dump files.
Sometimes Frame just winks out without a trace.

In addition to managing any damage to the .fm file, it is not uncommon for the crash to screw up the page numbering declared in the .book file for all .fm files in the book (open or not), that are after the .fm file that crashed. Easy to fix, but wierd.

Each document directory here has, among other subdirectories, one which is used to store working/backup/recover files after crashes.

Because Frame crashes can be due to latent corruption in the .fm file, you can be editing a book and discover way late that major sections have turned to garbage. Having archives helps.

R

r0ybatt3Author

Known Participant

"Go no longer between saves than you care to re-create."

Again, the problem has absolutely nothing to do with material added since the last save. I'm talking about formatting that has existed for quite some time. These are the things that are now being lost.

"Frame has always had that 'feature'."

I have been using FrameMaker for 10 years and have never seen this. My experience has been with Frame 5.5, 7, 7.2 and 8 -- and I have not previously noticed corrupted formatting as the result of a crash except for the color being lost from conditional text definitions. But that was far more minor because the correct conditional text definition could be imported from another document. With what I am seeing now, the paragraph tags are still defined correctly (so there is no point in importing them). But it's as if someone went through the whole document and did an override of massive numbers of headings and phrases, so that the standard paragraph-tag definition is not being used -- with the additional weird caveat that when you highlight the text and look at the name of the tag, FrameMaker does not add an asterisk to indicate a deviation. This has also happened to several character tags, though with the character tags FrameMaker does use an asterisk to show a deviation.

"In addition to managing any damage to the .fm file, it is not uncommon for the crash to screw up the page numbering declared in the .book file for all .fm files in the book (open or not), that are after the .fm file that crashed. Easy to fix, but wierd."

Interesting, I have not seen this.

Van Kurtz

Inspiring

r0y,

Again, the problem has absolutely nothing to do with material added since the last save. I'm talking about formatting that has existed for quite some time. These are the things that are now being lost.

I believe Error7103's point is that when a crash occurs, you should have no expectation that the .recover file should be OK, no matter how long the formatting has been there. During a crash, anything can happen. To say that is is the crash that is changing the formatting is .... well.... to be expected....because a crash is a crash and anything can happen.

In my experience (fm9), the recover files are usually OK, but there is no guarantee. So, in stead of worrying about the recover file's not being good, simply save often and open only the most recent saved file and go from there.

Van

Jeff_Coatsworth

Community Expert

I would expect that to happen because unless you saved just before the crash, FM has no way of knowing that there have been changes made when it craps out. The bigger question is what's causing your crashing? Have you tried to figure that part out?

R

r0ybatt3Author

Known Participant

No, you've misunderstood. The crash is changing the documents. So, for example, everything in the document is formatted and displaying correctly. The file has been saved. The file has always been formatted correctly through many weeks' worth of editing and saving. There have been no problems. Then the crash occurs and, when I reopen the document, it has been altered -- lots of paragraph tags have lot their bolding (and possibly other changes, though the bolding is the most obvious). This never happened in FrameMaker 8.

I do not know what is causing the crashes, though I think it is related to saving as a PDF. It's not happening with alarming frequency, but the side effect of ruining the formatting makes it a much bigger problem than it would be otherwise.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.