When "saving a Frame 2015" file as a PDF the square bullet character defined in the Bulleted paragraph tags does not display in the generated PDF file. This is a new issue since PDFs were generating fine up until a month or so ago. I did have to swap out the original Zapf Dingbat font (old post script font) that produces the square bullet with a different font, ITC Zapf Dingbat.
First screen shot w/bullets, second one no bullets
Any suggestions how I can fix this?
What font are you using for your text? Most modern fonts with unicode support have the dingbats built in, so it may not even be necessary to use a character tag to format your bullet.
Try using the Windows Character Map, set it to the font you are using in the text, and search for "square". If it's there, you can copy and paste it into the autonumber window without applying a character tag. If it isn't, then the Webdings font (which I believe comes with Windows) has a filled square in it.
I'm not familiar w/unicode support for modern fonts or using the Windows Character Map. I'll do a web search to figure out more about these so I can try your suggestion.
The legacy method of doing this was to have a Character Format that invokes the legacy Zapf Dingbats font (for example named "Dingbats"), and define the bullet in the Paragraph Format > Numbering as:
Character Format: [Dingbats]
In the post FM8 era, it's more common to be using a font that populates Unicode (Arial does)
U+25A0 BLACK SQUARE
dispense with the Zapf, and define the Bullet A/N simply as:
Character Format: [As Is]
Thanks Bob_Nilan. I had a feeling that the legacy dingbat was the root of the problem and the Frame template that uses it is quite old as well. Unfortunately our team is married to the template so how much I can change the font, bullets, and template are very limited. But this info does help. Thanks.
A template that's still using legacy overlay fonts may have originated pre-FM8. It's possible that a later FM might might damaged the internal coding when updating to Unicode.
Be_eM's insight below might also apply, and in any case the document behavior would also be consistent with any change to whether the font is embeddable at all.
Legacy overlay fonts still work. They're just not a great idea for stewardship, as you can see. I'm having to use some in an FM2019 project because I'd need characters defined in Unicode SMP (codepoints above U+FFFF), and my fonts have them, but FM still doesn't support SMP yet (nor does Windows, really).
I don't know if this is related, but I recently had exactly the same problem with a self-created symbol font. The font was displayed correctly in FrameMaker, but saving to PDF made these symbols (also used for bullet lists) disappear. I've been able to solve this problem by re-saving the font - originally a TTF - to OTF format. This works flawlessly now. If I recall correctly, this happened only when exporting to an RGB PDF, with FrameMaker's own CMYK engine the bullets were working. Couldn't do that, though, because I was outputting an Arabic (R2L) document. Possibly means that Windows PostScript didn't like the TTF font, for whatever reason.
Great info, thanks Be_eM! I will definitely try this.
You are a genius!! When I tried saving my Frame book file just now I selected the CMYK options instead of RGB and the bullets are back!!!!
Thank you, thank you!
Try this. When saving the PDF, choose File > Print and select the Adobe PDF printer driver. Click on Settings. Click on Edit.
Select Fonts on the left column. Change Subset to zero instead of the default 100%.
I did try using the File > Print and select Adobe PDF as the printer, but it did not correct the issue. I don't see the "Settings" option you mention so I cannot select specific fonts. Or can I just uncheck the box about Relying on system fonts?
Yes, definitely uncheck the "Rely on system fonts only" option. This is always causing problems and prevents fonts embedded in, e.g., EPS files from being written to PDF. However, this might not be related your current problem.