Opening PDF at specified page

[Andrew Poulos]

I have some js that looks like this:

fOpenPDFInNewWindow = function(url,page) {
var page = page || 1;
newPDF = window.open(url+"#pagemode=bookmarks&page="+page,
"location=no,menubar=no;toolbar=no,scrollbars=no,w idth="+800+",height="+600+"\"");
}

and some HTML that looks like this:

<a href="#"
onclick="fOpenPDFInNewWindow('http://www.domain.com/test.pdf',5); return
false;">test link</a>

In my testing the PDF always opens at the specified page yet the client
insists that in her testing it only ever opens at page 1. I thought that
this would be pretty straightforward but I'm stumped as to why it should
behave differently. The client is using IE 6.

Andrew Poulos

[Thomas 'PointedEars' Lahn]

Andrew Poulos wrote:

I have some js that looks like this:

fOpenPDFInNewWindow = function(url,page) {
var page = page || 1;
newPDF = window.open(url+"#pagemode=bookmarks&page="+page,
"location=no,menubar=no;toolbar=no,scrollbars=no,w idth="+800+",height="+600+"\""); ^ }
Eeek.

var newPDF;

function fOpenPDFInNewWindow(url,page) {
return (newPDF =
window.open(url
+ "#pagemode=bookmarks&page=" + (page || 1)
+ "scrollbars=yes,width=800,height=600"));
}
and some HTML that looks like this:

<a href="#"
onclick="fOpenPDFInNewWindow('http://www.domain.com/test.pdf',5); return
false;">test link</a>
Eeek 2. What about popup blockers, and what about absent script support?

<a href="http://www.domain.com/test.pdf"
onclick="return !fOpenPDFInNewWindow(this.href, 5);"Show PDF document</a> In my testing the PDF always opens at the specified page yet the client
insists that in her testing it only ever opens at page 1. I thought that
this would be pretty straightforward but I'm stumped as to why it should
behave differently. The client is using IE 6.

The client is not using only IE 6. They are also using either the Adobe
Reader plugin (or an equivalent) or the standalone Adobe Reader (or an
equivalent). Whether anchors within the PDF document are followed when
referred to as URI depends on both the browser and the used viewer
application. Older viewer plugins tend not to support anchors. And
external viewer plugins tend to not getting anything but the filename
from the browser, which downloads the resource to a file on the local
filesystem (temporary directory) first, and then opens the external
viewer with that file.

Probably one of the former is the case with your client, while you are using
more a recent viewer as a plugin. Check incompatibilities there; although
your code is unnecessarily complicated, error-prone and does not degrade
gracefully, certainly the main reason of the problem is not the code
because your client said that the PDF document is displayed.
PointedEars
--
When you have eliminated all which is impossible, then
whatever remains, however improbable, must be the truth.
-- Sherlock Holmes

[Thomas 'PointedEars' Lahn]

Andrew Poulos wrote:

I have some js that looks like this:

fOpenPDFInNewWindow = function(url,page) {
var page = page || 1;
newPDF = window.open(url+"#pagemode=bookmarks&page="+page,
"location=no,menubar=no;toolbar=no,scrollbars=no,w idth="+800+",height="+600+"\""); ^ }
Eeek.

var newPDF;

function fOpenPDFInNewWindow(url,page) {
return (newPDF =
window.open(url
+ "#pagemode=bookmarks&page=" + (page || 1)
+ "scrollbars=yes,width=800,height=600"));
}
and some HTML that looks like this:

<a href="#"
onclick="fOpenPDFInNewWindow('http://www.domain.com/test.pdf',5); return
false;">test link</a>
Eeek 2. What about popup blockers, and what about absent script support?

<a href="http://www.domain.com/test.pdf"
onclick="return !fOpenPDFInNewWindow(this.href, 5);"Show PDF document</a> In my testing the PDF always opens at the specified page yet the client
insists that in her testing it only ever opens at page 1. I thought that
this would be pretty straightforward but I'm stumped as to why it should
behave differently. The client is using IE 6.

The client is not using only IE 6. They are also using either the Adobe
Reader plugin (or an equivalent) or the standalone Adobe Reader (or an
equivalent). Whether anchors within the PDF document are followed when
referred to as URI depends on both the browser and the used viewer
application. Older viewer plugins tend not to support anchors. And
external viewers tend to not getting anything but the filename from the
browser, which downloads the resource to a file on the local filesystem
(temporary directory) first, and then opens the external viewer with that
file.

Probably one of the former is the case with your client, while you are using
more a recent viewer as a plugin. Check incompatibilities there; although
your code is unnecessarily complicated, error-prone and does not degrade
gracefully, certainly the main reason of the problem is not the code
because your client said that the PDF document is displayed.
PointedEars
--
When you have eliminated all which is impossible, then
whatever remains, however improbable, must be the truth.
-- Sherlock Holmes

[Andrew Poulos]

Thomas 'PointedEars' Lahn wrote:

In my testing the PDF always opens at the specified page yet the client
insists that in her testing it only ever opens at page 1. I thought that
this would be pretty straightforward but I'm stumped as to why it should
behave differently. The client is using IE 6.

The client is not using only IE 6. They are also using either the Adobe
Reader plugin (or an equivalent) or the standalone Adobe Reader (or an
equivalent). Whether anchors within the PDF document are followed when
referred to as URI depends on both the browser and the used viewer
application. Older viewer plugins tend not to support anchors. And
external viewers tend to not getting anything but the filename from the
browser, which downloads the resource to a file on the local filesystem
(temporary directory) first, and then opens the external viewer with that
file.

Probably one of the former is the case with your client, while you are using
more a recent viewer as a plugin. Check incompatibilities there; although
your code is unnecessarily complicated, error-prone and does not degrade
gracefully, certainly the main reason of the problem is not the code
because your client said that the PDF document is displayed.

Thanks for the help (lesson?) in JavaScript. Unfortunately I think the
problem is more "serious". I can get a PDF to open at a specified page
from my computer. I have a second computer on which I have loaded IE 6,
with the latest updates, and Acrobat 7.07, which I downloaded today,
installed.

On the second computer any content in the query string of the URL gets
ignored. That is, I cannot set pagemode, destination, page...

Of course it works correctly (or appears to) in FF 1.5. I wonder if it's
some new security feature of IE/Windows?

Andrew Poulos

[VK]

Andrew Poulos wrote:

I wonder if it's
some new security feature of IE/Windows?

Yes, it is. Windows XP SP2 activates very harsh popup blocker by
default. It is strange that your solution is still working for anyone:
either your users are not Windows ones, or the majority is using
outdated Windows platforms (98, 2000, ME).

If SP2 is installed, userAgent string contains "SV1", and it means 70%
chance that you cannot open new windows by script (highly generous 30%
left for customized settings).

I believe several months ago in this very group with a similar problem
I suggested you to start migration on popupless solution asap. You
ignored my advise as I can tell. :-(

;-)

[Andrew Poulos]

VK wrote:

Andrew Poulos wrote:

I wonder if it's some new security feature of IE/Windows?

Yes, it is. Windows XP SP2 activates very harsh popup blocker by
default. It is strange that your solution is still working for anyone:
either your users are not Windows ones, or the majority is using
outdated Windows platforms (98, 2000, ME).

If SP2 is installed, userAgent string contains "SV1", and it means 70%
chance that you cannot open new windows by script (highly generous 30%
left for customized settings).

I believe several months ago in this very group with a similar problem
I suggested you to start migration on popupless solution asap. You
ignored my advise as I can tell. :-(

No, I think you've misunderstood my question. A URL that points to a PDF
*is* opened with JavaScript when a user clicks a link. Popup blocking is
not the issue here. (Pointed Ears showed me how to make it less
"error-prone" and how to degrade it gracefully for users with JavaScript
turned off.)

The problem is that the PDF always opens on page 1 irrespective of the
query string contents. The Adobe site says that #page=5 should open the
PDF at page 5 (it does with FF and IE 6 on my computer) but it opens at
page 1 with IE 6 on other computers.

Even if I put the URL plus query string into the A's href it still opens
at page 1. The display URL in the address bar is correct but the page is
not.

My lament about security features was about some new(?) one added to PDF
display.

Andrew Poulos

[VK]

Andrew Poulos wrote:

No, I think you've misunderstood my question.
Sorry.
The problem is that the PDF always opens on page 1 irrespective of the
query string contents. The Adobe site says that #page=5 should open the
PDF at page 5 (it does with FF and IE 6 on my computer) but it opens at
page 1 with IE 6 on other computers.

I'm not aware of it. You should look at MSDN, but before you should
check is it a problem with a *newer* viewer or with an *outdated*
viewer which simply doesn't support this feature. Sometimes people
reinstall their beloved utils from CD's kept for years.

[Thomas 'PointedEars' Lahn]

Andrew Poulos wrote:

Thanks for the help (lesson?) in JavaScript.
You are welcome. You may see it as a lesson if you think you have learned
something from it :)
Unfortunately I think the problem is more "serious". I can get a PDF to
open at a specified page from my computer. I have a second computer on
which I have loaded IE 6, with the latest updates, and Acrobat 7.07,
which I downloaded today, installed.

On the second computer any content in the query string of the URL gets
ignored. That is, I cannot set pagemode, destination, page...
Hmmm.
Of course it works correctly (or appears to) in FF 1.5. I wonder if it's
some new security feature of IE/Windows?

Unlikely. It is rather an incompatibility between IE and the plugin. In
my previous job at the IBM Help Desk, we encountered strange problems with
the Adobe Reader plugin when IE was updated (with security patches), such
as that no PDF documents were displayed anymore. Reinstalling Adobe Reader
(any version above 5.0) fixed these problems. Maybe that works for you,
too.

But reviewing your code a second time, this line could be a problem:

newPDF = window.open(url+"#pagemode=bookmarks&page="+page,

Either "&page="+page is part of the query component of the URI, or it is
part of its fragment component (since you want to show a specific page of
the PDF document, the latter is more likely). If the former, it must be
placed before the first "#" (but after the first "?") and can be used as
is (provided that `page' is a decimal number); if the latter, it must be
placed after the first "#" and must be encoded with encodeURIComponent(),
especially the "&". See also RFC3986 "Uniform Resource Identifier (URI):
Generic Syntax", section 3 et seqq.
HTH

PointedEars
--
The name of God: J-E-H-O-V-A. "J"...argh!
[crashes right through the "J"-slab, hanging over a hidden abyss
....eventually pulls himself out of the trap] Oh boy, what a fool
I am???!!! In Latin, Jehova starts with an "I"! -- Indiana Jones

[Andrew Poulos]

But reviewing your code a second time, this line could be a problem:

newPDF = window.open(url+"#pagemode=bookmarks&page="+page,

Either "&page="+page is part of the query component of the URI, or it is
part of its fragment component (since you want to show a specific page of
the PDF document, the latter is more likely). If the former, it must be
placed before the first "#" (but after the first "?") and can be used as
is (provided that `page' is a decimal number); if the latter, it must be
placed after the first "#" and must be encoded with encodeURIComponent(),
especially the "&". See also RFC3986 "Uniform Resource Identifier (URI):
Generic Syntax", section 3 et seqq.

I tried a number of possible permutations with no success. I'm running
out of time so I converted the PDF to HTML and used anchors. This will
give me more time to play with it before the next PDF I have to try to
link to.

Additionally, page 8 of this doc:
<url:
http://partners.adobe.com/public/dev...Parameters.pdf

gives examples one of which matches my usage.

This page:
<url: http://www.adobe.com/support/techdocs/317300.html >
says "If you use URLs other than HTTP and HTTPS, such as server
locations (\\servername\folder), then set the link to open to a set
destination using the procedure in the following section" but I don't
quite understand it. Do they mean that other than HTTP of HTTPS you
should use destinations rather than page numbers?

Andrew Poulos

[Thomas 'PointedEars' Lahn]

Andrew Poulos wrote:

Please provide attribution of quoted material. Your Thunderbird does this
automatically by default, in a configurable way. Don't remove that.

But reviewing your code a second time, this line could be a problem:

newPDF = window.open(url+"#pagemode=bookmarks&page="+page,

Either "&page="+page is part of the query component of the URI, or it is
part of its fragment component (since you want to show a specific page of
the PDF document, the latter is more likely). If the former, it must be
placed before the first "#" (but after the first "?") and can be used as
is (provided that `page' is a decimal number); if the latter, it must be
placed after the first "#" and must be encoded with encodeURIComponent(),
especially the "&". See also RFC3986 "Uniform Resource Identifier (URI):
Generic Syntax", section 3 et seqq.

I tried a number of possible permutations with no success. I'm running
out of time so I converted the PDF to HTML and used anchors. This will
give me more time to play with it before the next PDF I have to try to
link to.

Additionally, page 8 of this doc:
<url:

http://partners.adobe.com/public/dev...Parameters.pdf

>

gives examples one of which matches my usage.

Well, if Adobe wants to redefine URIs, that is their prerogative; however,
they should not expect this to work in other user agents than Adobe Reader.
And neither should you.
This page:
<url: http://www.adobe.com/support/techdocs/317300.html >
says "If you use URLs other than HTTP and HTTPS, such as server
locations (\\servername\folder), then set the link to open to a set
destination using the procedure in the following section" but I don't
quite understand it.
Obviously they have not really a clue what they are talking about. "Server
locations", more precisely UNC (Uniform Naming Convention) paths, are not
URLs (which are a subset of URIs). However, such resources also can be
referred to by a "file:" URI: file://server/share.
Do they mean that other than HTTP of HTTPS you should use destinations
rather than page numbers?

It would appear that they mean to use the destination like an anchor in an
HTML document instead of the page number if either the reference is not an
URI, or the protocol component of the URI is not http(s).

However, maybe you have better luck defining a destination for each page of
the PDF document.

I do not think further discussion about this issue is on topic here.
PointedEars