[17422] in Athena Bugs
Re: acroread plugin vs standalone
daemon@ATHENA.MIT.EDU (t. belton)
Mon Dec 13 13:44:17 1999
Date: Mon, 13 Dec 1999 13:43:55 -0500 (EST)
From: "t. belton" <tbelton@MIT.EDU>
To: Camilla R Fox <cfox@mit.edu>
cc: web-agents@mit.edu, bugs@mit.edu, cfyi@mit.edu
In-Reply-To: <199912131823.NAA03335@brute-force.mit.edu>
Message-ID: <Pine.GSO.3.96L.991213132855.16981A-100000@iphigenia.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Right now one problem is that we can't get consistent reports on which
methods work and which don't. For Athena workstations we basically have
four ways:
1. Acroread as a plugin on Suns.
2. Acroread as a helper app on Suns.
3. Acroread as a plugin on SGIs.
4. Acroread as a helper app on SGIs.
It's my opinion right now that #1 doesn't work well on a regular basis,
that #3 rarely works at all, but that #2 and #4 have their problems also.
In short, we have received at least one complaint about each method and we
don't really know where to go from here.
Since this summer, the default Netscape preference is to use the
standalone version over the plugin. Unless the user has older settings in
a local .mailcap file, this is the case (and the user would have to switch
to use the plugin by hand, in Preferences).
Right now - since no one is getting consistent results - my best
suggestion is to document the method of switching back and forth. It may
even be that some PDFs work better in the plugin and some work better in
the helper. We already know that the helper does better with very large
PDFs - that's one reason we switched to it as the default. This may be
something which the user has to twiddle on an ongoing basis. I know that's
rotten from a support standpoint, but I don't know a better answer.
To change over:
1. Edit | Preferences | Navigator | Applications
2. Select handler for "Portable Document Format," press Edit
3. Either "Application" or "Plug In" will be checked. Depending
on which one you're switching to:
a. If you're switching to the application and there's not
already a path in the textbox, it's
/mit/acro/arch/@sys/bin/acroread %s
b. If you're switching to the plugin, it should already be
in the dropdown list as nppdf.so. If it doesn't show up,
and isn't shown in the 'about:plugins' list, then your
Netscape has something seriously wrong, since that is a
path/wrapper issue and not a config issue.
-Todd
On Mon, 13 Dec 1999, Camilla R Fox wrote:
>
> I've noticed a lot of users having problems with viewing PDF documents
> from netscape. They see the acrobat splash screen, but they get an
> empty browser window.
>
> danw tells me that the follwing transaction (and others in the thread)
> in the bugs discuss meeting deal with the problem.
>
> [17320] daemon@ATHENA.MIT.EDU (Dan Winship) Athena Bugs
10/27/99 12:35 (20 lines)
> Subject: Re: sgi 8.3.19: Adobe Acrobat
> Message-Id: <199910271634.MAA136498@antharia.mit.edu>
>
>
> I don't know what the right solution is, but there are several
> questions in the OLC queue (and I've also seen a number of walkin
> questions in the SIPB office, about it) which are presumably this
> problem, and nobody has been able answer them. (With the number of
> class notes out in PDF format, this has fairly high urgency.)
>
> If you can't get a fix out really soon, do you think you could send
> mail to cfyi with a description of the best known workaround, (I hear
> frobbing netscape's settings can be done manually) in sufficient detail
> that we can expect a user to understand?
>
> Making netscape-fix fix it would also be a more than adequate
> solution.
>
> -Camilla
>
