I forgot to mention that, starting with FM10, you can do font
replacement easily. Open the Fonts pod, click the missing ZapfDingbats
font and then click the Replace button. The Fonts Replace pod will open
and you will be able to specify the BT version of the font as a
permanent replacement. Of course, that assumes you aren't trading the
file back to someone who wants it to continue to use the original font.
I don't want to have to make any changes to the books or documents if I can avoid it. If I have to do that, I'll edit the styles to use the bullet characters in the bullet paragraph tags' font and purge all use of dingbat fonts.
Something's scrambled in that post.
> If I have to do that, I'll edit the styles to use the bullet characters in the bullet paragraph tags' font and purge all use of dingbat fonts.
If these documents ever need to be opened in an FM version earlier than 8.0, using native bullets probably won't work, as they will probably be Unicode (UTF8) code points that will be treated as three nearly random characters.
I'd suggest instead converting all instances to a Variable, so that managing them can be done in one place per document.
On a legacy platform:
Var Name: char.dingbat.bullet
Var Def: <Dingbat>\xc6
Char Fmt: Dingbat is defined to be font family Zaph Dingbats
On a Unicode platform:
Var Name: char.dingbat.bullet
Var Def: <Dingbat>\u2022
Char Fmt: Dingbat is defined to be any font family that has code point 2022 populated, perhaps even just set to "As Is".
They'll never need to be opened in anything older than FM10.
Bullet characters from the font used by the bullet paragraph tags work fine in a wide variety of output formats. I've been using them in documents I created from scratch and in one document I cleaned up.
Dang. Once again, the forum software scrambled my post. Let's try again. Here's a repost:
I haven't tried it, but I think that should be:
Zapfdingbats, *, *, *= ZapfDingbats BT, *, *, *
And be sure it is in the [UnknownToKnownFontMap] section, not [WindowsToFrameFontAliases] section.
> Zapfdingbats, *,*= ZapfDingbats BT,*,*
Tried that, no change.
Tried deleting Adobe Pi Std and mapping it to ZapfDingbats BT, no change.
I guess I'll call Adobe support.
I couldn't get font substitution to work, so I just hacked Adobe Pi Std with Type Light to add the bullet glyphs and map them to l and n. Didn't work until I figured out I needed to reboot Windows to apply the font change.
Still not working, but it's no longer a font substitution issue so I'll start another thread.
Why not just get a Postscript version of ZapfDingbats and install it on your machine? I still use it on my Win7 64-bit platform with no issues. This would save a lot of hassles.
I already have Zapf Dingbats BT on my machine, which works fine, but FrameMaker is substituting Adobe Pi Std instead. I have no reason to believe that buying another version of Zapf Dingbats would make FrameMaker behave any better.
Simply comment out the subsitution line the maker.ini file, e.g.
; Zapfdingbats, *,*= Adobe Pi Std,*,*
I already tried that and it didn't work.
On newer Windows & Frames, there is more than one maker.ini. The user-specific one is read last, as I recall.
Interesting, but FM10 seems to have copied the changes from the maker.ini in my user settings directory to the copy in the FM10 program directory.
That worked, thanks. I installed a Type 1 copy of Zapf Dingbats from an Illustrator 7 CD-ROM, commented out the substitution, replaced the hacked font, deleted .font_cache, rebooted, and it's working fine.
And I guess the fundamental problem was that the documentation department's master font directory contained only the .pfm, not the .pfb.