Font problems after 10.6.7

Hi,
For some reason, I do not have the Select "Save as Adobe PDF" you mention in your workaround available.

Anyone care to explain how to fix this or why I do not have the workflow available?

Thanks, and so long for now, TOM

Anyone care to explain how to fix this or why I do not have the workflow available?

That option only appears if you've installed Acrobat Pro. I believe you need at least version 9 for that. Now sure if version 8 of Acrobat Pro works in Snow Leopard.

Yes, as Kurt noted, only Acrobat version 9.0.x installs the Acrobat plug-in listed in the work-around. That's why I'm still searching for a freeware solution of some sort.
No luck so far. (I guess like Kurt I dream of the long-ago days of System 6, 7, 8, and the wonderful NeXt machine that used display postscript instead of pdf...)

etresoft wrote:
Create a document in TextEdit with Minion Pro. Print to PDF. Open the PDF in preview. Select some portion of the document and copy to the clipboard. Now paste into Office 2011 - crash.

I don't have Office (2011 or otherwise) installed so I can't test this directly. The best I could do was pasting the text into OpenOffice 3.x. That produced no crash.

The fix for this bug is Apple's to make. Then, they update that ISO standard to state "Due to historical reasons, these two parameters and their references must be listed in the same order they are used. Embedded fonts using the Deflate algorithm must use these specific parameters."

If this change in the ISO standard is a fix for the 10.6.7 problems people are reporting, and it causes no problems with other applications relying on the current one, then ISO needs to update the standard. You can't really call it an Apple bug if its PDF generator obeys the current standard.

canonballs wrote:
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?

A bug is a bug. There are perfectly legal reasons for wanting to do that.

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

It isn't the "Times New Roman" part, it is the "PS" part.

I haven't read through the Preview/Quartz 10.6.7 generated files in enough detail to figure this out yet, but I can tell from inspecting them, since it's the first few lines of their header files, that Preview/Quartz rendering says it has generated PDF v. 1.3. As I understand it, that's from 2000, and isn't the ISO
standard. And as I noted, other apps (like ghostscript) claim that the pdf's from Preview/Quartz from both OS 10.6.6 and OS 10.6.7 do not conform to the Adobe pdf spec. Ghostscript amusing reports this:
" ** >>>> Mac OS X 10.6.3 Quartz PDFContext <<<<
** Please notify the author of the software that produced this
** file that it does not conform to Adobe's published PDF
** specification."
Interestingly, the Adobe Plug-in says that it has converted the pdf file to v1.7 -- and as noted, this pdf seems well-formed: it does not crash other apps; it does not make ghostscript complain, etc.
So, all in all, this would seem to be prima facie evidence that this is a bug in the Preview/Quartz rendering engine -- which is to say, something for Apple to fix. I hope they fix it soon.

etresoft wrote:

canonballs wrote:
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?

A bug is a bug. There are perfectly legal reasons for wanting to do that.

I agree. I was just curious about a particular scenario.

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

It isn't the "Times New Roman" part, it is the "PS" part.

I am afraid I still don't understand rcberwick's problem. If a font was present in the original document then there is nothing wrong with it persisting into a Preview-extracted portion thereof. Expecting Preview to get rid of all PS fonts in all .pdf documents around is unrealistic. Now if a TNR PS header appears in an excerpt out of nowhere or in places where there should be a header of a different font then that points to a different (although, conceivably, related) issue than the one you described with tag order and innovative font subsetting/compression.

canonballs wrote:
I am afraid I still don't understand rcberwick's problem. If a font was present in the original document then there is nothing wrong with it persisting into a Preview-extracted portion thereof.

There is nothing wrong with persisting the font in the Preview-extracted version. The problem is that if that font was originally put into the PDF incorrectly, it will persist in an incorrect form in the clipboard.

Expecting Preview to get rid of all PS fonts in all .pdf documents around is unrealistic. Now if a TNR PS header appears in an excerpt out of nowhere or in places where there should be a header of a different font then that points to a different (although, conceivably, related) issue than the one you described with tag order and innovative font subsetting/compression.

Preview is just a viewer and is unrelated to the problem. The problem is that the MacOSX printing software generates incorrect PDFs when these fonts are used. Once the PDF is created, there is no real way to fix it. Even if Apple issues a fix, the PDF will be still be wrong - forever. Hopefully, when Apple releases a fix, you will be able to re-save your PDFs to valid formats.

The problem is that while the Preview/Quartz renderer in 10.6.6 produces correct pdfs from documents that have embedded Type 1 PS fonts, the version in 10.6.7 does not.
This is a bug in Apple's OS.

Kurt Lang wrote:
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.

A very minor point because these same people are the least likely to update their OS. 😉

… In most businesses of any size, users do not have access to update their software….

The same thing applies to some extent here, as well as to schools & so on. It is the job of IT departments to be be aware of update issues & plan accordingly.

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.

What is being suggesting amounts to a lowest-common-denominator approach: live with bugs & software that doesn't comply fully with accepted standards until everybody is ready to update everything to bug-free, standards-compliant versions. That will never happen.

More to the point, it greatly hampers innovation. Instead of designing software to one set of well-defined standards, it has to be designed with a slew of exceptions for whatever doesn't follow those standards. The end result is bloated, nearly impossible to maintain apps.

Don't get me wrong: Apple must fix any bugs in its software & anything that violates the ISO standards, even if it isn't strictly speaking a bug. But incorporating workarounds for those things present in the code of non-Apple products isn't a viable longterm solution.

etresoft wrote:

canonballs wrote:
I am afraid I still don't understand rcberwick's problem. If a font was present in the original document then there is nothing wrong with it persisting into a Preview-extracted portion thereof.

There is nothing wrong with persisting the font in the Preview-extracted version. The problem is that if that font was originally put into the PDF incorrectly, it will persist in an incorrect form in the clipboard.

OK, that much I get. rcberwick, however, was complaining about 10.6.7-extraction from a .pdf off the net which was presumably not produced by 10.6.7's pdf generation libraries, and so is apparently assumed healthy. That user also noted that they liked the 10.6.6-extraction from the same file much better:

rcberwick wrote:
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.
...

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 >>

rcberwick's point apparently is that TNR PS, being PS, is likely to cause problems in further 10.6.7-use of the snippet while Helvetica, being something else, is not. My first question, still unanswered, is whether TNR (PS or otherwise) had any legitimate business in the original file.

etresoft wrote:
Preview is just a viewer and is unrelated to the problem. The problem is that the MacOSX printing software generates incorrect PDFs when these fonts are used.

Right. But once you tell Preview "Save As" it will call on some of that software.

Once the PDF is created, there is no real way to fix it. Even if Apple issues a fix, the PDF will be still be wrong - forever.

Thanks, I get this. Forever is a long long time.

rcberwick wrote:
I haven't read through the Preview/Quartz 10.6.7 generated files in enough detail to figure this out yet, but I can tell from inspecting them, since it's the first few lines of their header files, that Preview/Quartz rendering says it has generated PDF v. 1.3.

Not that things aren't confusing enough already but I just did some random checks of various PDF files from assorted sources to see what PDF version is mentioned in their headers. Only one I could find mentioned v 1.7. Even those that were installed on my Mac by the Adobe's Photoshop Elements version 9 installer typically mention v 1.5, & according to Preview & embedded info in the files they were generated & created by Adobe's most current version of Distiller for Windows.

I can't check what Acrobat Pro or the like create on my Macs since I don't own them, but PSE 9 is a recently released Adobe product, appears to use its own PDF generator rather than the Quartz one, & it produces v 1.3 PDF's as well. I've also noticed that as far back as 10.6.2 the Quartz generator produces v 1.3 PDF's, so this isn't unique to either 10.6.7 or to the Quartz generator.

I have no idea what this means, other than it would appear the PDF version has little or nothing to do with these problems.

What is being suggesting amounts to a lowest-common-denominator approach: live with bugs & software that doesn't comply fully with accepted standards until everybody is ready to update everything to bug-free, standards-compliant versions. That will never happen.

Exactly. It's a lousy position, but I'm mostly basing that on two things.

1) Everything worked fine in 10.6.6. Whatever Apple changed in 10.6.7 caused the issue, so they should be the ones to fix it.

2) The logistics are rather overwhelming. If you compare how many Macs are running 10.6.7 to the install base of Acrobat across Windows, OS X, Linux, etc., it's got to outnumber 10.6.7 by at least a factor of 10. Not fun for those who need to fix OS X, but far fewer than the number of Acrobat installs to upgrade or update.

Don't get me wrong: Apple must fix any bugs in its software & anything that violates the ISO standards, even if it isn't strictly speaking a bug. But incorporating workarounds for those things present in the code of non-Apple products isn't a viable longterm solution.

Fully agree on both points. Preview and other third party apps have no trouble viewing PDF files generated from 10.6.7. It seems to be only Acrobat that has trouble. But, it does go deeper than that. This is also causing havoc with PostScript RIPs and printers. That would involve updating hundreds, more likely thousands of printer drivers across multiple OS's. It's just too much compared to fixing OS X.

I have no idea what this means, other than it would appear the PDF version has little or nothing to do with these problems.

That is correct. Apple's pdf machine has been generating 1.3 for many years already. It will produce 1.4 if the document contains transparency.

Kurt Lang wrote:
1) Everything worked fine in 10.6.6. Whatever Apple changed in 10.6.7 caused the issue, so they should be the ones to fix it.

Another way to look at it might be that Apple's change exposed the issue.

2) The logistics are rather overwhelming. If you compare how many Macs are running 10.6.7 to the install base of Acrobat across Windows, OS X, Linux, etc., it's got to outnumber 10.6.7 by at least a factor of 10.

The logistics considerations are not just about the relative installed bases but also about the long term consequences of a "fix" that helps perpetuate poorly defined standards or disregarding already established & accepted ones. We have been down this road before & it leads to duels between proprietary standards, portability problems that take years to resolve, high prices, & captive markets.

Preview and other third party apps have no trouble viewing PDF files generated from 10.6.7. It seems to be only Acrobat that has trouble.

That is a vast oversimplification. The reports are all over the place regarding which apps have what problems with what fonts.

This is also causing havoc with PostScript RIPs and printers. That would involve updating hundreds, more likely thousands of printer drivers across multiple OS's. It's just too much compared to fixing OS X.

This assumes much that is as yet not well understood about the nature or cause(s) of the problem(s). For instance, there are conflicting reports about what fonts cause problems with PostScript RIP's.

Basically, all I'm saying is it is premature to speculate about the best fix or who should do it. The last thing we need is a string of hastily contrived quick fixes that solve some users problems while creating bigger problems for others.