Font problems after 10.6.7

I would like to thank Kurt and all the members of this thread for their insights.
I truly wish this issue was limited to a font issue local to one's own computer.
But unfortunately, as far as I can tell, this is not the case: any downloaded pdf file
that happens to contain embedded fonts of the sort Kurt describes will cause
further issues downstream. Thus, it will not in general suffice to purge one's own computer of
the PS-Type 1 fonts that cause the problems. Any file that contains such fonts
cannot be manipulated properly by Preview, and further use of them (e.g., insertion
into Office 2011 word or ppt files), will crash either of these apps (and many others we
have now tested). In a university environment (where I am), where hundreds of Macs
are downloading thousands of pdf journal papers per day, this simply won't wash.
A simple example will suffice. Below is an excerpt of the pdf file downloaded from a
science journal today. The first snippet is from the pdf generated by Preview on 10.6.7;
the second, the same place in the corresponding pdf file generated by Preview 10.6.6.
Note that Preview 10.6.7 version has used the font BOICKG+TimesNewRomanPS-Italic --
this is the kiss of death. Preview 10.6.6, with the same downloaded PDF, has encoded this as
/UCRAEJ+Helvetica, which is OK.
Therein lies the rub. There's no way to 'fix' all the fonts, and this may be part of why different users have reported different experiences.
And for us at least, this spells real trouble --- there's no way to 'downgrade' many, many hundreds of machines.

10.6.7 Preview generated pdf (bad font):
<< /Type /FontDescriptor /Ascent 868 /CapHeight 771 /Descent -216 /Flags 32
/FontBBox [-223 -248 1063 900] /FontName /BOICKG+TimesNewRomanPS-Italic /ItalicAngle
0 /StemV 81 /AvgWidth 500 /MaxWidth 1222 /StemH 32 /XHeight 578 /FontFile3
29 0 R >>

10.6.6 Preview generated pdf at same position (OK)::
<< /Type /FontDescriptor /Ascent 770 /CapHeight 717 /Descent -230 /Flags 32
/FontBBox [-951 -481 1445 1122] /FontName /UCRAEJ+Helvetica /ItalicAngle 0
/StemV 0 /MaxWidth 1500 /XHeight 637 /FontFile2 29 0 R >>

Not entirely true. If you disable your OpenType Postscript fonts, then PDFs that you generate will be fine. Anyone else will be able to read them.

Once a PDF document gets created on 10.6.7 with these fonts, it will be trouble downstream for others for years to come.

If you must use these fonts to create PDFs, you must downgrade to 10.6.6. If you don't need to create PDFs with these fonts, then just disable them to ensure that you can't accidentally use them in a PDF.

This is a serious issue, but it has a number of workarounds. The big problem is that it is a fairly hidden issue that most people will be unaware of until their PDFs cause trouble for other people. Those other people will just blame Apple and, this time, they would be right.

That is very helpful--
That is the answer we wanted to know (that..at last count, 12 Apple Techs have
not been able to answer):
What is the procedure for disabling all OpenType Postscript fonts without knowing what they will be?
Does one require an exhaustive list of all such fonts before one encounters
them in a new, downloaded document (since different journals use different fonts)?
Or is there a global way to turn them all off before every seeing them? If so, that would be a real fix,
and a big help to us.

What is the procedure for disabling all OpenType Postscript fonts without knowing what they will be?

In general OpenType TrueType fonts will have a .ttf or .ttc extension. OpenType PostScript will always have a .otf extension. But just to make things difficult, an OpenType TrueType font can also have a .otf extension.

There are a couple of ways to tell what type of .otf font you have. Activate your OpenType fonts and then launch Quark XPress 8.x. In the list of fonts, Quark separates OpenType fonts by type. A TrueType font will have the standard green and black OpenType icon. PostScript OpenType fonts will be shown with a red and black icon. Suitcase Fusion 2 and 3 also note which type of fonts they are. A PostScript font will be shown in the Type column as OpenType - PS, and a TrueType version as OpenType - TT.

One thing I haven't checked with these methods is if either Suitcase or Quark simply looks to see what the extension is, or if they actually check the font's tables. Files with a .otf extension which contain only CFF data will always be a PostScript font. So if other tables are present in the font, the programs would know that a particular .otf is actually TrueType.

There may be other ways to find out which are which, but these are ones I've found so far.

Perhaps I was not entirely clear. The "bad" font,
BOICKG+TimesNewRomanPS-Italic
is not in my System - not anywhere.
I have no OpenType postscript fonts in my System.
The font has been placed there mistakenly
by the Preview/rendering program in 10.6.7, because it is a mapping
of the font embedding in the downloaded PDF.
That is why I stated that this is a problem that runs beyond what
is going on in one's own local computer -- a quick scan of random
journal articles from Science, Nature, Cell, etc. show that they all embed
Open Type Postscript fonts in their online articles. But while 10.6.6
mapped them to OK fonts, 10.6.7 does not (viz., the example displayed earlier).

rcberwick wrote:
Or is there a global way to turn them all off before every seeing them? If so, that would be a real fix,
and a big help to us.

Run FontBook. Go to the Preview menu and select "Show Font Info". Next to the "Kind" column it will show what kind of font it is. Start at the top and go down the list. Every time you see OpenType Postscript, click the disable button at the bottom of the window. Most of the affected fonts will have a "Pro" suffix.

The font is embedded inside the PDF file. That way, systems that don't have that font can still display it nicely. Another option is to try to match the font with something close that you do have, but that isn't very common anymore.

You are correct that it does go beyond your local machine. Any PDF documents you create with these fonts will be unreadable with Adobe and apparently Microsoft software. You create a PDF and it looks fine, so you send it off. The recipient won't be able to open it. You print your tax documents to PDF and save them. You get audited years later, you are using different software, and your PDFs are unreadable.

Not only does Apple have to fix the bug, now they have to support both Adobe-variant files and their own variants that 10.6.7 is creating. Peachy, eh?

Right - that is the problem. But what is the solution? When one examines the files with emacs (which we did - that is where those extracted fragments displayed earlier come from) - one can see how Preview is mis-mapping fonts.
Disabling fonts was what we tried earlier today: first turning off via Fontbook, then deleting, all such
PS fonts. But this had no effect. That's why I said there are, as far as one can tell, there are
no OT PS-Type 1 fonts in the System. But, as soon as one downloads a pdf file
from another source, with embedded PS fonts, Preview/rendering 10.6.7 maps them,
in a way that causes crashes, that Preview rendering 10.6.6 did not. There is no way to control
this behavior, so it seems.
So much for 'portable document format'.

There isn't any mis-mapping. The font is inside the PDF file. Any other fonts you have are not related. All the instructions on disabling fonts is so that you will not create any new PDFs with these fonts. If you already have the PDFs, there is nothing you can do. They shouldn't be crashing Preview though. Do you have any examples of the documents that crash Preview? That would be a new issue.

Kurt Lang wrote:
Not necessarily more difficult to fix, but far more difficult to implement as it would require all users of Acrobat on both the Mac and Windows to update Acrobat Pro and the Reader. I can't even guess how long that would take, or if you could even convince all users to do it.

I still don't see why this would be any more difficult to implement than any other update. Adobe regularly & often releases updates for essentially all of its products to fix all manner of bugs & compatibility issues, including printing & rendering ones. Why would this be any different?

OK, I have actually found one work-around for the case where Preview is writing out
bad font information. Instead of using "Save As" from Preview, the following sequence
creates pdf files that can be successfully read into Acrobat, Distiller, Word/PPT 2011, etc - this
assumes you have the Adobe plug-in/Acrobat Pro:
1. In Preview: Print > Select "PDF" > Select "Save as Adobe PDF"
2. This converts the file to Adobe-compatible PDF & launches Acrobat Pro
3. Save the resulting file; it prints normally and can be inserted into other docs normally.
An inspection of the file with emacs reveals that the 'bad' TimesRomanPS font has not been included by the Adobe plug-in converter, as it is in the Preview-generated pdf. (It also shows that Adobe is writing out PDF v 1.6, rather than the PDF v 1.3 specs, which is what Preview says it is writing out -- that's strikingly out of date.)
BTW, pdf2ps, tried as another workaround, which uses ghostscript to generate postscript, will fail on the Preview-generated pdfs (under 10.6.7), but succeeds on 10.6.6 Preview-generated pdfs, even though it complains a bit about the quartz engine 'not following Adobe standards'.

rcberwick wrote:
... any downloaded pdf file
that happens to contain embedded fonts of the sort Kurt describes will cause
further issues downstream. Thus, it will not in general suffice to purge one's own computer of
the PS-Type 1 fonts that cause the problems. Any file that contains such fonts
cannot be manipulated properly by Preview, and further use of them (e.g., insertion
into Office 2011 word or ppt files), will crash either of these apps (and many others we
have now tested). In a university environment (where I am), where hundreds of Macs
are downloading thousands of pdf journal papers per day, this simply won't wash.

While I would oftentimes re-crop in Preview a .pdf paper from a journal for nicer printing, doesn't the scenario you describe—inserting excerpts into derivative documents—amount to plagiarism and/or copyright infringement?

I am not trying to detract from the gravity of the issue you describe, I am just surprised that instances where this issue becomes an actual problem are as widespread as you imply.

The first snippet is from the pdf generated by Preview on 10.6.7;
the second, the same place in the corresponding pdf file generated by Preview 10.6.6.
Note that Preview 10.6.7 version has used the font BOICKG+TimesNewRomanPS-Italic --
this is the kiss of death. Preview 10.6.6, with the same downloaded PDF, has encoded this as
/UCRAEJ+Helvetica, which is OK.

Why is Times New Roman "the kiss of death"? Is it just the wrong font or is TNR inherently evil for some reason?

A fair point; but such things generally fall under "fair use" doctrine, as long as the original source is cited. Certainly for instruction, this is a widespread practice in our experience.
But back to the main point: the downloaded files are often generated by TeX or other production systems that have embedded Postscript fonts -- in this case, TimesNewRoman. Inspection of the full original pdf reveals this. The 10.6.6 version of Preview/Quartz rendering engine handled these properly; the 10.6.7 version does not. The difference between the two pdf files produced can be easily exhibited (see the previous postings).
As I just noted, there is a workaround if one has Acrobat Pro and uses "Print > Save as Acrobat PDF"
Apparently, the Acrobat plug-in works correctly, unlike the Preview/Quartz rendering engine.
We are currently searching for a freeware work-around to this; as noted, ghostscript doesn't seem to do the trick, but perhaps some other converter would.

rcberwick, thanks for your response

rcberwick wrote:
But back to the main point: the downloaded files are often generated by TeX or other production systems that have embedded Postscript fonts -- in this case, TimesNewRoman. Inspection of the full original pdf reveals this. The 10.6.6 version of Preview/Quartz rendering engine handled these properly; the 10.6.7 version does not. The difference between the two pdf files produced can be easily exhibited (see the previous postings).

Most TeX engines would use type 1 PS fonts (in Windows .pfb format). .otf fonts are used by Xe(La)TeX, Lua(La)TeX and suchlike—I would conjecture not many journals use the latter. Are you saying that the description/header/encoding of a type 1 TNR (legitimately present in a document?) cannibalises those of other fonts in the course of Preview processing?

Message was edited by: canonballs

Why would this be any different?

Time and implementation. Let's just assume Adobe would fix both Acrobat Pro and the Reader for versions 8, 9 and X.

They make it available and millions, perhaps billions of users will now have to update their apps. There are many users who are not computer adept. They will not install or update anything without help from a relative or friend. A rather minor point, but they're out there.

Much more of a hindrance is business. In most businesses of any size, users do not have access to update their software. So imagine companies the size of 3M, Microsoft, U.S. Bank, etc., with all of those employees waiting for IT to get to their computer to install a simple update. It would take weeks, likely months.

Schools also lock down their computers. Now you've got millions of those machines waiting to have Acrobat updated by staff members. And of course all of the students updated their machines, which they can at least do by themselves.

And this all assumes that everyone knows that it needs to be done in the first place. How many months will it take for word to get around that every copy of Acrobat in the world needs to be updated?

Apple has only recently introduced 10.6.7. There would be far fewer users overall who would need to apply a patch to fix the issue.