From: Thomas 'PointedEars' Lahn on
David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>> > Beline wrote:
>> >> "Joe Nine" wrote:
>> >>> Beline wrote:
>> >>>> how to programmatically determine Adobe Acrobat PDF plug-in version
>> >>>> installed in Firefox and Opera?
>> >>>> Is it possible with Javascript?
>> > [...]
>> >
>> > Like flash, Acrobat is a plugin, however you should keep in mind that
>> > Adobe Acrobat is not the only PDF viewer. Foxit, for example, Safari
>> > has its own preview for PDF files that does not rely on any Adobe
>> > plugin.
>> >
>> > The web page might provide a link to the PDF and leave it up to the
>> > user to download that or view it as he wishes (right click and save,
>> > etc). It may be worth considering providing a link to a reader/plugin.
>> However, plugin detection appears to be rather easy to do in the targeted
>> environments using navigator.plugins.
>
> Yes, but what would you do differently if the plug-in was detected (or
> not).

There are several possibilities.


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: David Mark on
On May 30, 1:26 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Garrett Smith wrote:
> >> > Beline wrote:
> >> >> "Joe Nine" wrote:
> >> >>> Beline wrote:
> >> >>>> how to programmatically determine Adobe Acrobat PDF plug-in version
> >> >>>> installed in Firefox and Opera?
> >> >>>> Is it possible with Javascript?
> >> > [...]
>
> >> > Like flash, Acrobat is a plugin, however you should keep in mind that
> >> > Adobe Acrobat is not the only PDF viewer. Foxit, for example, Safari
> >> > has its own preview for PDF files that does not rely on any Adobe
> >> > plugin.
>
> >> > The web page might provide a link to the PDF and leave it up to the
> >> > user to download that or view it as he wishes (right click and save,
> >> > etc). It may be worth considering providing a link to a reader/plugin.
> >> However, plugin detection appears to be rather easy to do in the targeted
> >> environments using navigator.plugins.
>
> > Yes, but what would you do differently if the plug-in was detected (or
> > not).
>
> There are several possibilities.
>

I realize that, but where PDF's are concerned (as opposed to Flash), I
can't think of a single good one.
From: Thomas 'PointedEars' Lahn on
David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> However, plugin detection appears to be rather easy to do in the
>> >> targeted environments using navigator.plugins.
>> > Yes, but what would you do differently if the plug-in was detected (or
>> > not).
>> There are several possibilities.
>
> I realize that, but where PDF's are concerned (as opposed to Flash), I
> can't think of a single good one.

For a simple example, you could use DOM scripting to remove the link to the
Adobe Reader download then. Then the Reader plugin is scriptable, of
course. And the Acrobat/Adobe Reader API supports scripting of PDF
documents with an ECMAScript implementation (called "JavaScript for
Acrobat")¹, so you could serve an enhanced document that makes use of that.


HTH

PointedEars
___________
¹ <http://www.adobe.com/devnet/acrobat/javascript.html>
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: David Mark on
On May 30, 2:40 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> David Mark wrote:
> >> > Thomas 'PointedEars' Lahn wrote:
> >> >> However, plugin detection appears to be rather easy to do in the
> >> >> targeted environments using navigator.plugins.
> >> > Yes, but what would you do differently if the plug-in was detected (or
> >> > not).
> >> There are several possibilities.
>
> > I realize that, but where PDF's are concerned (as opposed to Flash), I
> > can't think of a single good one.
>
> For a simple example, you could use DOM scripting to remove the link to the
> Adobe Reader download then.

The downside is that detecting the PDF plug-ins (and their versions),
even in non-IE browsers appears to be non-trivial (if not impossible),
so you may remove a useful link. The upside would seem to be nil
(what harm can a link do?)

> Then the Reader plugin is scriptable, of
> course.

As is Flash. Of course, it's a complete nightmare. I wonder if
Acrobat plug-ins are any different.

> And the Acrobat/Adobe Reader API supports scripting of PDF
> documents with an ECMAScript implementation (called "JavaScript for
> Acrobat")¹, so you could serve an enhanced document that makes use of that.

And what would you look at in the navigator object to determine
whether such an enhanced document is feasible? Assuming there is
answer to that, how about IE? Then I wonder if you can detect a
viewer that is not a browser plug-in.

And the OP asked simply for the version number, which (from reading a
cited treatise) appears to be impossible to nail down. And even if
you could nail it down, making inferences from version numbers is a
slippery slope (see also Flash).
From: Thomas 'PointedEars' Lahn on
David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> David Mark wrote:
>> >> > Thomas 'PointedEars' Lahn wrote:
>> >> >> However, plugin detection appears to be rather easy to do in the
>> >> >> targeted environments using navigator.plugins.
>> >> > Yes, but what would you do differently if the plug-in was detected
>> >> > (or not).
>> >> There are several possibilities.
>> > I realize that, but where PDF's are concerned (as opposed to Flash), I
>> > can't think of a single good one.
>> For a simple example, you could use DOM scripting to remove the link to
>> the Adobe Reader download then.
>
> The downside is that detecting the PDF plug-ins (and their versions),
> even in non-IE browsers appears to be non-trivial (if not impossible),

ACK, see below.

> so you may remove a useful link. The upside would seem to be nil
> (what harm can a link do?)

It was an *example*.

>> Then the Reader plugin is scriptable, of course.
>
> As is Flash. Of course, it's a complete nightmare. I wonder if
> Acrobat plug-ins are any different.

Judging from their bogus introduction ("JavaScript 1.5, ... formerly known
as ECMAScript") I am inclined to say No, but that a thing can be labeled a
nightmare has not yet prevented anyone from using it when that was required.

>> And the Acrobat/Adobe Reader API supports scripting of PDF
>> documents with an ECMAScript implementation (called "JavaScript for
>> Acrobat")¹, so you could serve an enhanced document that makes use of
>> that.
>
> And what would you look at in the navigator object to determine
> whether such an enhanced document is feasible?

Perhaps navigator.plugins[n][m].type. You are right that this particular
plugin is apparently, unfortunately, silent about its version, so even
navigator.plugins[n].version is not useful here.

I had overlooked the version part in the original question and responded
only to whether it was possible to detect the plugin. However, once you
have detected the plugin, you could use feature-testing and maybe you can
access the object in the document to retrieve the plugin version.

> Assuming there is answer to that, how about IE? [...]

IE/MSHTML is not among the target environments in this thread. Stop trying
to raise the bar, please, you are preaching to the choir.


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)