Missing Font, But Font Isn't In the Document

Report · Jun 28, 2011

Hello,

We're all using FrameMaker 10 on Windows 7.

My client and I are receiving the good old missing fonts error message, specifically:

The "ITC Stone Serif Std Medium Ital Italic" Font is not available.

It will be replaced by "Times New Roman Italic".

The "ITC Stone Sans Std Semibold" Font is not available.

It will be replaced by "Times New Roman".

First, the fonts are installed.

Second, Remember Missing Font Names is turned OFF. (Unchecked, cleared, etc.)

Third, the fonts are NOT in the document. I have saved the document as MIF. I have searched for the font names. Nothing. When I open the MIF file in FM, I don't get an error. But I save it as a .fm file, open it, and I receive the same error messages.

We don't use these fonts. We don't want them in our documents. I'm doing a massive clean up to get rid of old formats. About half of the files do not have any problems, but half do. I have tried everything:

- Generating a list of fonts. If the fonts are found, then I go in and manually apply the Default Para Font. Usually, doing this removes the font from the list of fonts. However, I still get the messages.

- Importing formats from a known good file.

- Editing the MIF, to the point of removing the entire paragraph, character, font, and table catalogs. (I started by deleting references to ITC Stone x, then went on to the more drastic measures.)

- Changing the default printer.

- Copying the text and pasting it into blank files based on known good files.

- I tried editing the maker.ini file to substitute fonts directly, but that didn't work. I may have been doing that wrong, though.

I've got over 10 years of FM experience, and I've never encountered a font problem that editing the MIF couldn't fix.

All of the documents came over from Frame 6. They're all in the same book.

We need to be able to work on the book file as an entity, without having to open the files that contain errors and leave them open.

Does anyone have any ideas?

Thank you very much!

~Robyn

Report · Jun 28, 2011

Robyn,

EPS files are allowed to request fonts from the embedding document. Do you have any of those in your document? They would be listed after this kind of comment in the EPS file:

%%DocumentNeededFonts:

- Michael

Report · Jun 28, 2011

I found that one of the Bad files was using a graphic, tip.eps, that wasn't being used by a Good file. I deleted the graphic from the document.

I'm still getting the font errors.

One of the other Bad files is not using tip.eps, but it still gives me errors too.

Thank you for trying! It seemed like a promising answer.

Are there any other ideas? I really am at my wit's end here.

~Robyn

Report · Jun 28, 2011

Robyn,

There are two other hidden places that font defintions may lurk.

The first is in Table Catalog definitions. FM not only stores the paratag names used in the cells, but the actual font properties for each cell of the header and first row.

The second place could be an unintended click with the Text Line tool and not entering anything. This inserts an empty text string anyway using the font properties of whatever text was used last. In old templates, you could have all sorts of stuff hidden this way. To find these sorts of insertions, click on a page outside of the text frame and then do a Select All on the page (Ctrl+A). If you see handles outlining a small square, you've got one. These are often on Reference pages where Reference frames has been named or renamed.

With FM 10, you can use the Replace Font feature to globally make a permanent change to replace the undesired font(s) with your current ones. But that still doesn't necessarily solve the problem of where they were lurking and errant text objects.

Report · Jun 29, 2011

There are two other hidden places that font defintions may lurk.

The first is in Table Catalog definitions.

The second place could be an unintended click with the Text Line tool...

Wouldn't the font name be visible in the MIF in those cases?

In the present case, I'm guessing that the remaining "missing" fonts (names not visible in MIF) are also arising as invocations within imported objects.

One such from an EPS has already been reported. I'd expect an FM text inset to be able to cause this problem. I wouldn't be surprised if imported DXF, DWG, RTF and SVG objects could cause this problem. Indeed, almost any import-by-reference file format that supports text, and isn't flat raster, could have the potential to cause this problem.

Report · Jun 29, 2011

I have saved the document as MIF. I have searched for the font names.

So far, we've been discussing only import-by-reference objects that might be bearing unrequited requests for fonts.

I'm also wondering if it's possible that copy-into-document objects might do this as well, in a stealth manner. It strikes me as possible that these could end up as impenetrable HexEncoding text blocks in the MIF, and would not reveal requested font names to a text editor. Frame, of course, would interpret the HexEncoding into FM data structures, and then burp up a complaint.

None of this, however, explains why it's possible to get a "missing font" error when a font with the exact same space-and-case name is reportedly installed. I might guess that this could happen if, for example, the document is asking for a code point (say, some non-Latin Unicode character) that is out of range for an older 8-bit TrueType or Type1 font.

Report · Jun 29, 2011

I found the problem, but I'm not sure why it was a font problem to begin with:

Unresolved cross-references.

FM couldn't open all of the files in the book. Therefore, it couldn't update cross-references. It "thought" cross-references were unresolved.

I figured this out by deleting one page at a time from a Bad file. Then, I deleted one paragraph at a time from the Bad pages to determine that the cross-references were causing the problem.

I was cleaning up the book - deleting paragraph, character, cross-reference, table, and conditional text formats and master and reference pages. I then imported formats from a known Good file. The more files FM could open without errors, the fewer font errors I received. After I was able to generate/update the book, the font errors were gone.

Some of the font calls were on a reference page that was found only in select files. However, one would think that would show up in the MIF.

My best guess is that FM couldn't update the cross-reference formats without updating the cross-references, so it "thought" the text was still in the wrong font. That begs the question: Which came first, the unresolved cross-references or the missing fonts?

Of course, it doesn't explain why FM was complaining about a font that is installed.

Thank you everyone who took the time to answer. I'm sure this won't be the last time I run into this problem, and now I'll have a lot more knowledge for next time.

~Robyn

Report · Jun 29, 2011

Robyn,

In general, when I experience missing font problems and want to update a book, I open all the files in the book, which allows me to close any dialog boxes about missing fonts. Of course, my missing font problems are typically due to missing fonts.

Anyway, had you done open all the files and then updated the book, FrameMaker should have told you there were unresolved cross-references. Once fixed, in your case, the missing font problem would have gone away.

Van

Report · Jun 29, 2011

Of course FM was telling me that xrefs were unresolved when I opened each file. However, I did not connect missing fonts with unresolved cross-references. Why would I?

There were a number of problems with the book, which is why I was cleaning it up. I couldn't generate/update the book, even with all of the files open. But that's another story...

~Robyn