Acroread Problem

[Tom 'Needs A Hat' Mitchell]

On Tue, Mar 23, 2004 at 09:49:11PM -0500, Matthew Saltzman wrote:
> On Tue, 23 Mar 2004, fred smith wrote:
> > On Tue, Mar 23, 2004 at 03:50:10PM -0500, Matthew Saltzman wrote:
> > > On Tue, 23 Mar 2004, John Thompson wrote:
> > > > Fritz Whittington <f.whittington at att.net> wrote:
> > > >
> > > > > If you really liked Acroread, you can re-install it.  As long as you
> > > > > remove the plug-in, Mozilla will honor your choice of an external
> > > > > "helper" app, like xpdf.  The problem is, that IF there's a plugin
> > > > > installed that can handle a file, then Mozilla will happily ignore
> > > > > your attempts to set up a helper app to handle it.  You might even
> > > > > discover that Acroread will work as an external helper app.  But at
> > > > > least then you can have your choice.
...
> > > Do you have mozplugger installed?
...

> > The difference is: the nppdf.so file is a PLUGIN, which causes Acrobat
> > to (appear to) open up in a browser window. Otherwise it would most
> > likely open as a separate app (unless some other plugin such as mozplugger
> > or plugger is managing the plugin for you).
....
> As another poster pointed out, you can change what app gets loaded (and
> whether it's swallowed) in /etc/mozpluggerrc.

Is there a per user mozpluggerrc protocol?

It looks like:

  cp /etc/mozpluggerrc ~/.mozilla/mozpluggerrc

is the first safe step in debugging this.

I mention this because I dislike tinkering with a global system
resource in /etc if a per user resource will let me do the same thing.
And yes per user resources can confuse debugging for us shoulder
surfers.

I see this on the mozdev.org pages.  Snipped from
http://plugindoc.mozdev.org/linux.html

    "If installing plugins without root permissions, use
    ~/.mozilla/plugins instead of the plugins subdirectory where Mozilla
    is installed. You may have to create this directory first. Mozilla
    Firefox also uses ~/.mozilla/plugins for this.

    "Some plugins may require your version of Mozilla to be compiled
    with a specific version of gcc. You can use about:buildconfig to
    check which version of gcc was used to compile your browser."


I also see ~/.mozilla/pluginreg.dat on this system and wondered 
how to regenerate it and what the sources of data are.

I also noted that plugger has changed names to mozplugger
(mozplugger-1.5.1.tar.gz) and wonder what might happen if
both were on the system.

    "MozPlugger was branched out from Plugger 4.0 in February 2003 by
    Louis Bavoil. Now, its code is much smaller and cleaner (no .c
    #include for instance)."


And for the older plugger I see an answer to one of my own questions:
http://mozplugger.mozdev.org/

    "Notes:
    "* You may need to delete your local $HOME/.mozilla/pluginreg.dat
    file for mozplugger to be enabled correctly. (It will get
    regenerated).
    "* To add more helpers, edit /etc/mozpluggerrc. The window name
    can be obtained using the utility xprop(1x). Type "xprop WM_CLASS"
    and click on a window."

Hmmm they have people editing /etc/mozpluggerrc so make a backup...


-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.