FrameMaker 10 Crashes when I do a Find and Replace of a character format

Combs, Richard richard.combs at Polycom.com
Wed Feb 22 07:20:50 PST 2012


Joseph Lorenzini wrote:
 
> Please keep in mind that the "Character Format" option in the find
> dialog box doesn't exist until FM 10.  

That's simply not true. Both Find Character Format and Find Character Tag have been there as long as I can remember (at least 5.5 or 6). I'm looking at a 7.2 Find/Change dialog set to Find Character Format right now. 
 
> In answer to your questions:
> 
> 1)  I am doing this  because I first want to zero out all the
> formatting and then inherit a specific formatting from the body text.
> this ensures that i ONLY find text that is bolded and is body text and
> not finding bolded paragraphs that are  bolded because of the paragraph
> format, such as H1 or H2.

Then steps 7 and 8 are unnecessary. When the Find Character Format dialog opens, it has the settings at the text cursor. At Step 4, put the text cursor in bolded body text, and step 9 is also unnecessary. Saves a few keystrokes. :-)  

> 2) I do not  believe I am applying  on top of the format override but
> rather replacing the format override with the char tag. When I did my
> testing in a single FM file, I tried this once on one piece of text
> that had the bold override applied to it. Prior to the the find and
> replace, I searched for character format overrides and the find
> mechanism flagged this text as having an override. After the find and
> replace occurred, I searched for character format overrides and the
> find mechanism did NOT flag this text as having an override

You may be right. It's been a long time since I've dealt with ad hoc char formatting (in fact, my interface customizations eliminate all the easy ways to apply ad hoc formatting, like the B button, Ctrl+b shortcut, etc.). I do know (just confirmed, in 7.2 at least) that if you apply a char tag and then apply a different char tag on top of it, the characteristics of the first (that aren't changed by the second) still remain. But FM remembers only the second char tag (it has only one "bucket" for storing that info) and marks it with an asterisk, indicating an override. 
 
> 3)In the FM data model, my understanding is that part of a character
> format is the char tag. So when I do a copy special and copy the
> character format, I am getting the character format tag in addition to
> everything else associated with the character format.

Yes, I should have said "not _just_ the char tag itself." It's the "in addition to everything else" that I was trying to point out. If every place you paste has "everything else" the same as the place from which you copied, there's no problem. But if you copy from a body text pgf and paste to, for instance, a table text pgf that uses a different typeface .  
 
> 4) I was doing a find and replace across the entire book. I do this all
> the time and when I do I don't have a document open. I've never had a
> problem before. In any case, I have experimented with the find and
> replace when all the docs are opened and the crash still occurs.

Sorry to hear that it crashes anyway. For some people, at least, book operations have been more stable when some or all of the documents are open. It was worth a try. 

Good luck with the FM engineer. I'll look forward to learning the resolution, since moving to FM 10 is in my not-too-distant future. :-} 

Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
------
rgcombs AT gmailDOTcom
303-903-6372
------









More information about the framers mailing list