Viewing PDf files

I have the same problem in DevonThink and DevonAgent. Both are the latest versions and installed in /Applications (well, symlinked from Applications to a separate, case-insensitive partition I had to create for poorly-written apps cough adobe!), and I run them as a user without admin privileges.

If I open up a URL containing a PDF, for example tech.natemurray.com/higher_order … edures.pdf , I am prompted for my admin name/password – presumably to choose an application to associated with .pdf files. Note that in Finder, .pdf files are associated with Preview, though I do have Acrobat Reader 7 installed.

The interesting part comes when I authenticate and the Applications folder is displayed. Both Preview and Adobe Reader 7.0 are greyed out ,so I cannot select them to handle the file.

The end result is that I have to cancel out of the selection, which leaves me with a blank page instead of the contents of the .pdf file.

Three things bug me about this:

  • Shouldn’t DA and DT be able to handle a PDF URL natively using PDFKit?
  • Isn’t association of an application with a file type considered a User Preference, thus not requiring admin privileges?
  • Shouldn’t the default association in Finder (Preview) be used by default?

I should note that downloading the pdf and importing it into DT works fine, but downloading the pdf and opening it in DA fails. Also, I am only prompted for the handler once every time DA/DT is started: after that, the “lack of a handler” is cached.

Any ideas?

There are times when I curse Adobe. :slight_smile:

If you don’t need Adobe Reader for other reasons, I would encourage you to junk it. In any case, remove the Adobe plugin from the Internet Plugins folder in your User Library (and also in your boot volume Library, if it’s there). You do not need the plugin to view PDF files in your browser if you are running under Tiger, and in fact the Adobe plugin can cause problems.

If you haven’t done so, go to the Finder and select a PDF file. Open the Info panel (press Command-I) and tell the Finder to open this file under Preview, and also to open all PDF files under Preview.

I’ve also got Acrobat Professional 7 for other reasons, and this won’t harm Acrobat. (I’m not going to install Acrobat 8 yet, as I don’t yet need it, and it can raise other problems.)

Note that there’s not a command in DT Pro’s built-in browser to save a PDF file. But if you need to do that, just click on the URL to open the page in your default browser (DEVONagent in my case) and use the ‘Save As’ command. There’s actually a script available to save a PDF from Safari to your database, but it sends it to the main body of the database, which adds to the memory requirements for loading the database. (That won’t be a problem in DT Pro 2.0).

Yes, this is already done – as I posted, everything works fine in Finder (and all other apps). To get the version info out of the way: OS X 10.4.8, PPC, DA 2.0.3, DT Office 1.3 beta1 (hmm, check updates failed to find beta2).

I don’t use Adobe Reader except as a fallback when Preview messes up (rare, but it happens, especially with PDFs using newer Acrobat features). I am quite happy viewing PDFs in Preview.

The problem is twofold: 1) I get prompted for an application to use to view the specified file type (after authentication) when viewing a URL to a .pdf file, and 2) I am unable to select either Preview or Adobe Reader when prompted because they are disabled.

This happens only in DevonAgent and DevonThink; all other applications (e.g. Safari, Firefox) open PDF URLs just fine.

Need screenshots? I can provide 'em.

EDIT: I should add that this is not a new problem; it has occured ever as long as I have used DT and DA. I just finally decided to take the time to post about it :slight_smile:

Hi, edf. I can’t replicate your problem with viewing PDFs in the DT Pro browser or in DEVONagent. And I’ve never been asked to authenticate.

You’ve got something weird going on. Check your ownership/permissions in the Internet plugins section of your User Library. You should have read & write access to the Internet Plugins folder.

$ touch /Users/edf/Library/Internet\ Plug-Ins/test
$ rm /Users/edf/Library/Internet\ Plug-Ins/test

No problems there.

I created a new (non-admin) user, launched DA, and went to this thread in the browser. When I clicked on the PDF URL above, I was prompted for authentication “to make changes to DEVONAgent”.

I performed the same process as the admin user, and was not prompted for authentication (since I was already admin), but I was prompted for an application to handle the file.

To be sure, I downloaded a fresh copy of DA, copied it into /Applications (removing the original symlink), and ran it as admin: same problem. I moved DA to the desktop and tried the same URL as admin: same problem. I then set the default browser from Firefox back to Safari and tried the URL as admin: same problem.

I can reliably make this problem occur under any user. Based on your suggestion I checked out the global settings and found something interesting:

$ ls -1d /Library/Internet*
/Library/Internet Plug-Ins/
/Library/Internet Plug-ins/

The Plug-ins directory was created by, you guessed it, Adobe during the installation of the latest Acrobat Reader. I moved the Acrobat plugin to the Plug-Ins directory and deleted the Plug-ins directory. Same problem.

I moved the Acrobat pugin out of Internet-Plugins into /tmp : now it works, with DA opening the PDF file as expected.

I then downloaded the latest Acrobat Reader (8.0) and installed it along with the “safari plugin” with Acrobat not set to be the default reader for PDF documents. The installer put the plugin in Plug-Ins this time, which is good.

Safari opens the URL using PDFkit (or whatever the embedded viewer is), Firefox prompts me for a handler with the default set to Preview (correct behavior), Devon Agent does not prompt me (yay!) but instead shows a white page with the Acrobat icon in it (augh!). Clicking and ctl-clicking on the icon/page do nothing. Plugins are enabled.

In the interest of completeness I move the plugin into /tmp and, sure enough, DA works fine displaying the PDF inline as Safari does. Moving the plugin back breaks PDF display in DA.

So yes, the problem is caused by the Adobe Acrobat Reader installation, but DA is still doing something wrong. Both Safari and Firefox handle the URL correctly even though Acrobat Reader is installed. Removing the plugin is a fine workaround for now, since I prefer to launch Acrobat externally anyways, but this should be considered a bug.

EDIT: just realized this problem was already reported in a previous thread: devon-technologies.com/phpBB … php?t=2371

Yes, I agree that there’s a bug, but it’s Adobe’s.

Their plugin still seems to conflict with WebKit, and they shouldn’t be installing software that’s incompatible with Apple’s current operating system and with core Cocoa code like WebKit. Every time I update Acrobat Pro the cursed plugin is installed again. I always remove it immediately, and problems go away. From what I’m reading on MacInTouch user forums, Acrobat 8 is introducing some new problems. So I’m sticking with Acrobat Pro 7 until I can find a good reason to update to version 8.

Another good example was the Acrobat plugin to add to MS Word X the ability to produce PDF versions of a Word document. This plugin added a button to the Word toolbar. Click on it and it might produce a PDF copy of the open Word file, or crash Word. In any case, OS X already had the ability to print as PDF. The plugin didn’t add anything to OS X, but introduced compatibility problems and was best removed. Mac users complained about this for years on Adobe’s forum for Mac Acrobat.