default fonts in structured interface

[FieryPantone]

Dipping a cautious toe in the exciting waters of structured documentation; or, rather, trying my hand at using structured FrameMaker instead of / as well as my usual DITA IDE.

First minor question:

The Courier font is not available
The Zapfdingbats font is not available

Quite right; they aren't! so, how do I persuade structured FM to use something else, from now on and for ever? I'll probably have more interesting questions later ;-}

[Russ Ward]

Hi Niels,

There is some sort of entity settings file that Frame opens (in the background) during XML import that is actually a binary FM file and contains fonts like this. On FM11 on my machine it is here:

C:\Program Files\Adobe\AdobeFrameMaker11\Structure\entfmts

When FM attempts to read it during an import, you'll get these font errors if your machine doesn't have them. The solution is to make a backup of the file, then go into the original and just replace those fonts with something else. I'm not really clear on what this file is for but replacing fonts in it have never had any consequence for me. But like I said, make a backup

See if that fixes the problem.

Russ

[FieryPantone]

Ah. Sounds like a helpful answer, but also (alas) like a non-starter in this corporate environment. I may not (cannot, even) access config files, and the people who can access them refuse to touch them.

[peterc47573221]

Many thanks for pointing me to this file.

I had made sure that all my Dita Templates and Dita Output templates were formatted correctly, and yet whenever I created a new Dita topic, I would get the Missing Fonts message.

Opening entfmts (as administrator) and saving it again with the "Remember Missing Fonts" option deselected has cured this annoying behavior.

Cheers

[JonBe]

It seems incredulous but this problem still exists in 2019 and 2020 with the cause still being the use of the ZapfDingBats font in the entfmts file. The fix is exactly as Russ suggests; open the entfmts file, acknowledge the missing fonts and save. The maker.ini setting RememberMissingFontName must be =Off in both maker.ini's.

I have created a new bug report FRMAKER-9494 | Tracker (adobe.com) for this. I found another closed bug report that seems to suggest the bug was fixed, FRMAKER-5838 | Tracker (adobe.com), at least in 2019, which it is not. This bug also has a comment from @StefanGentz referring to a duplicate bug FRMAKER-3582, which I cannot find.

It is really confusing for users who are either manually importing XML, or using a plugin, and getting a message relating to a hidden process, that has nothing directly to do with the XML being imported. FrameMaker should only use fonts that are installed with it, or are guaranteed to be available on the system FrameMaker is installed on.

Jon    

[Bob_Niland]

re: … with the cause still being the use of the ZapfDingBats font …

It rather looks like there's some legacy headache here. FM used to bundle Type 1 ZDB as I recall.

PDF requires that ZDB be available, and at the time when that was enshrined, it would have been as an overlay/codepage font, with code points in the \x21—\xFE range (which in most other fonts are Latin characters and punctuation), mapped in FM by Font-Family (¶, ƒ or override).

PDF is likely stuck with needing to support this, even though most (perhaps all) of those glyphs did eventually get their own Unicode code points (in the U+2701—U+27BE range). Without having had much success in trying to find out, I'd expect a modern OTF named Zapf Dingbats to populate both code blocks, just in case.

… which may have no bearing on why the invocation is still hanging around at FM startup. I get complaints in FM2019 about "Times", before I've even opened anything (unstructured).