Client's files were created using Font Folio OTF, version 10. We have Adobe Font Folio OTF, version 11 (since Version 10 was no longer available at time of purchase).
When opening client's InDesign files, ALL Mathematical Pi LT Std OTFcharacters show (and PDF) as a multiplication dot.
Originally we thought that the problem was font embedding, since most of the InDesign files we've received from the client consist of placed, linked, and locked references to base files. However, we've also received unlocked, standard InDesign files and the problem persists.
We have tried emptying font caches, reinstalling fonts from the original disk (and emptying font caches again), etc. Because the files are locked, we are unable (and have not been contracted) to go in and change the fonts to the newer version. It is not clear whether the client will be able to purchase and replace the fonts themselves. Font Folio Version 10 is no longer available for sale (that I can see), so we cannot downgrade to the earlier version of the font.
Is there a reason that the newer version of the font is causing all glyphs to map to a single, incorrect glyph? Did the glyph map for Mathematical Pi LT Std OTF change when moving from FF OTF Version 10 to FF OTF Version 11? Has anyone else had problems with the font?
We have a mixture of files, some of which (client-created) use the Version 10 font and some of which (contractor-created) use Version 11. These two sets of files are now joining into one production stream. We're hoping that there's some systemic cure (such as an updated font that doesn't remap all characters).
Any advice will be welcome.
Are you saying that the PDF files produced by your client using Mathematical PI LT Std from Font Folio 10 also don't display correctly on your system that has access to Font Folio 11? Assuming that the PDF file has all fonts embedded (which is what always happens when you properly create PDF files via PDF export from InDesign), then the problem is unlikely due to any difference between versions of the Mathematical PI LT Std font. Acrobat always uses the embedded font when displaying PDF content, not any fonts you have installed on your systems; that's the idea behind embedding fonts in PDF files. And as far as we know, there were no significant changes, certainly not in the encoding, of the Mathematical PI LT Std font in Font Folio 11 as opposed to Font Folio 10.
A scenario that could cause the symptoms you see could be that the InDesign document in question was composed with the older Type 1 (non-OpenType) version of Mathematical Pi. At some point prior to creation of the PDF file, your client changed from use of the Type 1 version of the Mathematical PI font to the OpenType version and did not check the document to see what the ramifications were to such a drastic change. Going from Type 1 versions of fonts to OpenType versions are generally painless when dealing with Western Latin character sets. The same is not true when dealing with symbolic character sets or non-Western Latin character sets. In its Type 1 version, Mathematical Pi characters are mapped into lower 128 ASCII characters. In the OpenType version, however, the characters are encoded via Unicode; they don't map to A to Z and 0 to 9, for example. The same symptoms occur with other symbolic fonts such as Carta, Sonata, Zapf Dingbats, etc.
These are not PDF files; we are both using a content-management system
that allows areas of pages in InDesign files to be linked and locked,
so that we only have access to those portions of the page they want us
to edit. This is originally where we thought the problem was (since,
when creating PDFs, InDesign has to go to their servers, download the
locked information including art and text, and create the image).
These linked/locked pages display in low-res when we open them and
show the correct symbols, but PDF hi-res (correctly) and then show the
incorrect Math Pi characters.
However, we are seeing the same behavior of Math Pi when we open their
UNlocked, non-linked files. So the content management system does not
appear to be the source of the problem.
I will double-check that they are using the OTF, not the Type 1, font.
They have sworn to me several times that they are using Adobe Font
Folio OpenType only--indeed, they were extremely insistent on this
point. The font calls shown in the InDesign file are all for Open Type
We're extremely careful with font versioning; we don't use automatic
font activation, and we don't allow any fonts to be managed by the
system (other than required fonts). Because our font hygiene is so
stringent, we're completely stumped by this problem.
Thanks for your help.
[email signature deleted by host]
Please let us know what you find in your further investigation.
I have checked our libraries and there are no encoding differences between the encodings of the Mathematical Pi LT Std fonts on Font Folio 10 versus Font Folio 11; both have the same Unicode encoding. My personal experience with that particular font showed no differences between the OpenType version of that font between Font Folio 10 and Font Folio 11. And we haven't had any reports of problems comparable to what you are reporting.
What is true is that both Font Folio 10 and Font Folio 11 each provide both the Type 1 and the OpenType versions of the Mathematical Pi fonts. Adobe continues to provide those Type 1 versions due to the encoding differences between the Type 1 and OpenType versions to avoid exactly the encoding problems that it looks like you are seeing. However, there are differences in how the Type 1 and OpenType versions of the font are named.
Dov is correct that there was no relevant change in the font.
Would I be right to guess that you are running InDesign on a different platform than the files were created on? One of you is on Mac and the other is on Windows? If so, I believe I know the problem—and we can discuss that separately. The obvious solution would be for them to give you press-ready PDFs instead of native InDesign files.
All involved are on Macs. We are contracted to edit and then PDF the
InDesign files--we're a design and production house, rather than a
printer--so unfortunately we can't just get PDFs from them.
We are going to try running all PDFs on their end, and see if the
problem runs both ways--that is, see if they have similar problems
PDFing files with the newer font, as we have had PDFing files with
the older font.
I will let you know how it goes. It's still quite a mystery. I'm
asking them to double-check that they aren't accidentally running Type
1 instead of OTF on their end.
Design, Development, Production for Digital & Print
www.AARTPACK.com (for print and Flash)
www.AARTPACK.com/interactive (for Interactive Whiteboards & Digital
1330 Beacon Street, Suite 209
Brookline, MA 02446
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary, and/or privileged. This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed, or used by anyone else. If you are not the
intended recipient, please immediately delete this e-mail from your
computer system and notify the sender.
On further reflection, I believe the problem I was thinking of would only occur with Windows TrueType pi/symbol fonts, such as the system versions of Wingdings, Symbol, Webdings, etc. Not an issue here.
As you say, if one party was using the Type 1 version of the font, and the other was using the OpenType version, there would indeed be an encoding mismatch that could cause the symptoms you describe. However, the font names wouldn't be a precise match either, so you ought to get a missing font warning. Or, if the other font was active or auto-activated, you'd still be able to see which version was used in any particular text (Mathematical Pi vs Mathematical Pi LT Std).