Support PDF fragment identifiers/open paramaters

[GoogleCodeExporter]

What steps will reproduce the problem?
1a. Load the following URL: 

http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf#page
=8

1b. Load the following URL:

http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf#name
ddest=G3.1037262

What is the expected output? What do you see instead?

ER 1a: End up on (physical) page 8 (where you see a list of "URL examples"
that a plug-in might be expected to handle).

ER 1b: End up scrolled to the "URL Limitations" heading on page 8.

AR: End up on page 1.

What version of the product are you using? On what operating system?

0.9.8, Firefox 3, Mac OS X 10.5.2

Please provide any additional information below.

The referenced document describes all(?) the supported parameters, though
the most common are page and named destinations.  See also
http://schubert-it.com/pluginpdf/webdev/ for the parameters that the old
Schubert plug-in supported.

Original issue reported on code.google.com by smokey.ardisson@gmail.com on 22 Jun 2008 at 10:12

[GoogleCodeExporter]

PDF fragment identifiers are supported by Adobe Acrobat, but not Safari.

Original comment by colesbury@gmail.com on 5 Oct 2008 at 5:42

• Changed title: Support PDF fragment identifiers/open paramaters
• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Safari handle correctly fragment identifiers
(Tested with Mac OS X 10.5.6 and Safari 3.2.1 with Adobe Plugin) 

Original comment by innovi...@gmail.com on 30 Dec 2008 at 2:16

[GoogleCodeExporter]

Hi.  Thanks for this plugin; I find it integrates into FF really seamlessly, 
it's entirely reliable (unlike my experience of Schubert.it's) and it's not a 
JavaScript-supporting security hole (like Adobe's).

"PDF Open Parameters" and the accompanying RFC 
(http://tools.ietf.org/html/rfc3778#section-3 -- albeit informational) are a 
must-have for me, and this bug looks very stationary, so I've made a minimal 
start on fixing this; I'm using FF 3.6.16 [1], so this patch is against r102.  
(I'm new to add-on hacking, to Objective C and to JavaScript, so correct me 
mercilessly.)  It supports the bare minimum of #page=number on initial document 
load.

However, there's a still a problem I can't iron out: if you edit the fragment 
and hit enter, it should jump to the new fragment (as with HTML pages), but 
doesn't.  I've included a second, non-working patch just to illustrate what I 
tried in my newbie effort to fix that.  Assigning to window.onhashchange in the 
same way an in-page script would doesn't work, and I can't see what I'm missing 
nor how else to hook it.

Just barely working:
  http://gist.github.com/901859

Extra, broken code for fragment hacks:
  http://gist.github.com/901883

[1] I'll upgrade to FF4 soon and I'll be sure to file the zillionth dupe of 
"doesn't work on FF4 +1 me too!!!!11".  Seriously, though -- working, 
non-Adobe, fragment-supporting PDF support is really important to me, so I'm 
(patiently) waiting for the FF4 work on this plugin to finish before I upgrade.

Original comment by zakwil...@gmail.com on 4 Apr 2011 at 4:18

[GoogleCodeExporter]

That patch uses Objective C "fast enumeration" which requires the 10.5 SDK.  I 
forgot  the corresponding change to pdfplugin.xcodeproj/project.pbxproj SDKROOT 
(already in r103 and above), but just change "/Developer/SDKs/MacOSX10.4u.sdk" 
to "/Developer/SDKs/MacOSX10.5.sdk" in that file.

Original comment by zakwil...@gmail.com on 4 Apr 2011 at 4:29