The complaint: "Clicking on PDF links in Safari doesn't work."
The problem is that Apple's built-in viewer, Preview, doesn't display the contents of Acrobat Forms. In our (bivio's) case, the PDF forms in question are supplied by the IRS and filled-in by our software. In Preview, you can see the empty form but none of the data filled-in. You have to use Adobe Reader. Moreover, if you want Safari to open the files in Adobe Reader by default instead of Preview you must set the default application for PDFs in the Finder.
These instructions were tested with Mac OS X 10.3.2. Other versions of OS X may differ slightly, but the general idea should still apply.
The short story is 'Get Info' for any PDF file, change the 'Open With' settings from Preview to Adobe Acrobat, and then 'Change All...' to make all PDF files open with Acrobat.
Once you've done that, Safari will honor that setting and any PDF files downloaded will be opened with Reader instead of Preview.
Here is the play-by-play in case you need more detailed instructions:
1. Switch to the the Finder, (click the smiley icon in the Dock).
2. Locate any file whose name ends with .pdf. 
3. Select the file (click ONCE on it to highlight it).
4. In the File menu, select 'Get Info' (you can also use the keyboard shortcut Command-I) 
5. Reveal the 'Open with:' section of the window. (The Info window is divided into several sections which can be revealed or hidden using the triangle widget on the left hand side of the window. Use the triangle to make sure the 'Open with:' section is shown.) 
6. Change the 'Open with:' pop-up menu from Preview to Acrobat Reader
7. Click the 'Change All...' button, and click the 'Continue' button when you are prompted to confirm the change.
I personally prefer to leave Preview my default because it is much faster and the PDF files I usually read are not forms. I keep a copy of Adobe Reader around for the few times when I do need to deal with forms.
[1, 2, 3] It is hard to know where to draw the line in providing step-by-step written instructions. In this case I'm willing to assume you know how to navigate your computer with the Finder. I'll also assume that if you're interested in keyboard shortcuts, you probably don't need a description of Apple's command key. Somehow the triangle widget in the Info window crosses the threshold and demands a little explanation.
I appreciate that this is a solution, but I am frustrated by it. I prefer Preview to Adobe for most reading because it is thin. It loads quickly and renders quickly. Adobe is BIG. I create PDF forms and so I needed to make Acrobat (full version) my default app not even the slightly smaller (but still way too bloated) Acrobat Reader.
Changing this default, btw, also changes the preview mode in the print menu.
Where is openwith data stored? In the file itself or somewhere else? I know, for instance, that if you save a JPG in Photoshop, it opens in Photoshop by default. The same image tweaked by Graphic Converter opens there. Can we as creators of .ps content point to Preview unless there are forms? I know my adding that info won't override your default settings, but it could mine.
Do you have to set a default? Can it prompt you every time?
We're completely agreed on the benefits of Preview, especially considering print previews -- most unpleasant to have to wait for Acrobat there. That's even more reason to keep my default set to Preview.
I don't know where Mac OS stores these preferences, but my guess is that it's somewhere in ~/Library/Preferences. I assume one user's prefs won't effect another's. My casual search in there didn't turn up the exact location.
From my previous testing, it is possible to set the default application for individual files. If you skip the 'Change All...' step, the change will effect only the specific file and not set the default for all PDFs. But I see no simple way to configure the system to use Preview unless there's forms.
One could hack it by naming the formed pdfs differently, using a fdf suffix or something. Naming conventions can solve lots of problems. :-) But old-school Mac users will cringe at the need to use suffixes to distinguish the files.
Another trick that occurs to me would be more work. The java iText library I wrote about in another post could be used to test a pdf file for the presence of form data. Then one could compose a shell script or unix alias or perhaps a Java thingy which would open the pdf in the appropriate application. That Java thingy could probably be set as the default. Not a pretty solution in any case.
I created a link from a PDF to a "destination" in another PDF(in windows).It is working fine in windows . But in any of the MAC OS I could not reach the exact destination point when I click the Link.Could you please suggest me on this.
karthikeyan, I haven't ever worked with links in PDF files and I don't have any linked PDFs for experimenting, so I don't know if I'll be much use to you for this particular problem.
My best guess is about file names. I know very little about PDF links, but if you can link from one PDF file to another PDF file somehow the first PDF must store information about the second one, especially the filename. I know that Windows and Mac's have different filename conventions. Windows uses \ for it's path separator, Mac OS 9 and earlier use : and the unix family (including Mac OS X) use / for separating paths. Anyway, if the filename stored in the file contains the Windows path separators, it will almost certainly break links to those documents on non-windows platforms.
One other thought comes to mind. I have noticed on occasion that page numbers in PDF files often don't behave the way I would expect. In longer documents where there's a cover page and a table of contents and so on, there's a mismatch between the page numbers according to the PDF viewer and the page numbers in the table of contents. The PDF viewer seems to start counting with the cover page, whereas the numbers in the table of contents often start a few pages after that. So it may be that the link between the documents works okay, but the page numbering is off by a few. Maybe the Acrobat Reader on Windows handles this mismatch better than the Mac versions.
If you are at all inclined toward programming, my other post about hacking PDFs with iText and jython might help you track down the problem, but it might also be more trouble than its worth. A quick browse through google turned up a few promising places to start in the iText javadocs:
Hope all of that speculation helps.