Strange things happen. This particular strangeness is best described in the original message which I received:
Just now, I was working on my iMac, copy-editing an academic book in Acrobat Pro XI. For some reason I wanted to have a quick look at the PDF I was editing in Apple’s Preview (which is my default PDF viewer). Looking at the file in the Finder window, I was mildly disturbed to see that it showed just the generic PDF icon without its usual document preview. And it was also showing the Adobe filetype icon – with the red sticky-out “PDF” bit at the top left – rather than the Apple file icon that has the Preview icon on it and “PDF” at the bottom.
Anyway, double-clicking the file opened it in Acrobat rather than Preview, which isn’t normal. So I dragged it to Preview, and… nothing happened. Next, I switched into Preview and used its File > Open menu to find the file. There it was, listed… but it was greyed out!
The message continued, reporting for instance that QuickLook previews were now broken for PDF files. Its author had also tried using the Get Info dialog in Finder to re-associate PDF files with Preview, which established the association, but Preview remained unable to open the file.
To understand what has broken, you need to understand how OS X maps apps which can open different types of documents, to those different document types. Way back in Classic Mac OS days, this was achieved using hidden Desktop database files, which periodically needed to be rebuilt, as described here. OS X changed that, but as is so often the case, it has also made the system a little more opaque. It works fine almost all the time, but when it breaks it is much more of a puzzle.
Every app in OS X (and iOS) contains an Information property list file, named Info.plist. You can readily view this: select an app in the Finder, and use the contextual menu to show its contents. You will then see its top-level folder named Contents, within which is the Info.plist file, and various other folders and files.
Image may be NSFW.
Clik here to view.
One of the vital roles for Info.plist files is to specify which document types an application can open, and browsing an Info.plist such as that for Preview should reveal dictionary entries for the wide range of graphics file formats which Preview will open, and PDF files. If you were to manually edit the Info.plist file and remove reference to PDF documents, then that would disable Preview from opening those files.
Back in Classic Mac OS days, every file would have an associated four-character type code, such as APPL which meant that it was an application. Applications came with resources which listed the document types which they could open, and mapped document types to icons too. The Finder’s hidden Desktop databases were simply a compilation of those lists and mappings.
In OS X, associations are made using URLs, as shown in the Info.plist file. These are discussed here and here. However there is no method provided for users to adjust those data or mappings if they get muddled, nor to get OS X to refresh the data and eliminate potential conflicts within it. When things do go wrong – as in this user’s problems – they seem a complete mystery, and there is no evident cause or solution.
This is compounded by the effects seen in QuickLook previews, which most users would presume to be a separate part of OS X. Those with some deeper knowledge about QuickLook might try looking to see if there was a missing QuickLook plugin, perhaps, by typing qlmanage -m plugins into Terminal to check that. Sure enough they should then see the URL mapped to its QuickLook plugin:
com.adobe.pdf -> /System/Library/QuickLook/PDF.qlgenerator (675.43)
Image may be NSFW.
Clik here to view.
There is one free third-party tool which can reveal these URL-app associations in OS X: the venerable RC Default App, and using that to browse URLs relevant to PDF files should reveal the problem.
Unfortunately, everything looked fine in RC Default App, with PDFs properly associated with the Preview app. Starting up in Safe mode (with the Shift key held), which flushes a lot of system caches and generally freshens the system, as well as disabling third party extensions, was also unhelpful.
So the next question is whether Preview is trying to open PDFs, but lacking a key system component (or similar), and unable to do so. Because of its role in various bits of OS X, it is remarkably difficult to replace Preview with a copy, from a Time Machine backup prior to this problem starting, perhaps. However this user found that Pacifist reported that the checksum of his current copy of Preview was the same as that in a Yosemite installer, suggesting that the app is undamaged.
The next port of call is Console, to see what the logs show when Preview tries, and fails, to open a PDF. If we are lucky, it will report that a system component is missing or damaged, and gives us a helpful pointer to what really is broken.
If not, then there are some clues in some of the files which Preview opens, as revealed in Activity Monitor, including /System/Library/PrivateFrameworks/BookKit.framework/Versions/A/BookKit, and some .plist and .data files in ~/Library/Containers/com.apple.Preview/Data/Library/Saved Application State/com.apple.Preview.savedState. If the latter had become corrupted, then they might be stopping Preview from opening normally, perhaps. But we are now shooting in the dark.
I fear that in the end, this user will have to reinstall OS X, hardly the sort of thing that we should expect in version 10.10.5. It would have been so much easier had we been able to rebuild the Desktop.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
