Viewing PDFs inside WebKit apps can be accomplished, but I want to
stress that it has not been tested so is not supported by Adobe
Systems. The following methods are my personal advice and no
warranty is expressed or implied, etc etc.
That said...
To show PDFs in a WebKit app you will need to copy a particular
folder from within the Safari app package to within your WebKit app
package. This folder -- Safari.app/Contents/Frameworks -- is created
by Acrobat/Reader when it is first run on your system. This folder
contains symbolic links to the contents of the equivalent directory
within the Acrobat/Reader package (Acrobat.app/Contents/Frameworks).
That should allow a WebKit app to show PDFs (assuming you've
installed Acrobat or Reader)... but it shouldn't crash without it;
please send Tim O. a stack trace of the crash.
BTW, if you subsequently upgrade/change/move Acrobat/Reader, or re-
install, you will need to copy it again. Acrobat/Reader knows to do
this to the Safari frameworks directory but it can't know about all
WebKit apps. In your app you could symlink to Safari's symlinks, and
that may work for upgrades (but see the statement above about lack of
warranty etc).
I'm sure you all have two questions:
(1) What on earth made Adobe do that, um, "odd" thing?!
I won't go into the gory technical details but it has to do with the
mach-o loading mechanism and how it deals with hard-linked frameworks.
First AdobePDFViewer.plugin is just a bridge between Safari and
Acrobat/Reader. It doesn't do much except load Acrobat/Reader then
generally get out of the way. This means that essentially the entire
Arobat/Reader application is loaded into the Safari process -- and if
you've ever looked inside those packages, there is quite a bit to
them. Notice lots and lots of frameworks.
If you hard-link a framework to your executable -- like we do == mach-
o will automatically load that framework when you load your
executable... but it has to find the framework first. Your
executable has to tell the OS where it is, and until Tiger the
options for where they could be, when you were loaded into another
process, were very limited; so much so, in fact, that we decided that
creating this folder within Safari was actually the best option.
Believe me, it wasn't an easy decision to make, and Apple felt our
pain enough to provide a way out when running in Tiger.
(2) So if Tiger has a solution, will Adobe keep doing that?
Sorry, personal advice or no, Adobe signs my paycheck and "I can't
comment on features in future releases".
Hope this helps,
Rudi
On Apr 21, 2006, at 7:37 AM, Matt Gough wrote:
The Adobe pdf plug-in is not usable within any WebKit app apart
from Safari. Just having it installed for Safari will cause any
other WebKit app to fail when trying to view pdfs. In fact, once it
has been installed by Acrobat, you can get it to crash in Safari
just by duplicating your copy of Safari and running the copy. Why
they implement it the way they do is a complete mystery to me.
Matt Gough
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webkitsdk-dev/email@hidden
