Sakurai/pdf.js
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8,872 Commits 1 Branch 80 Tags 254 MiB
JavaScript 79.4%
Fluent 18.3%
CSS 1.5%
HTML 0.8%
b354682dd6
Go to file
Jonas Jenwald b354682dd6 [api-minor] Let LinkAnnotation/PDFLinkService_getDestinationHash return a stringified version of the destination array for explicit destinations 
Currently for explicit destinations, compared to named destinations, we manually try to build a hash that often times is a quite poor representation of the *actual* destination. (Currently this only, kind of, works for `\XYZ` destinations.)
For PDF files using explicit destinations, this can make it difficult/impossible to obtain a link to a specific section of the document through the URL.

Note that in practice most PDF files, especially newer ones, use named destinations and these are thus unnaffected by this patch.
This patch also fixes an existing issue in `PDFLinkService_getDestinationHash`, where a named destination consisting of only a number would not be handled correctly.

With the added, and already existing, type checks in place for destinations, I really don't think that this patch exposes any "sensitive" internal destination code not already accessible through normal hash parameters.

*Please note:* Just trying to improve the algorithm that generates the hash is unfortunately not possible in general, since there are a number of cases where it will simply never work well.

 - First of all, note that `getDestinationHash` currently relies on the `_pagesRefCache`, hence it's possible that the hash returned is empty during e.g. ranged/streamed loading of a PDF file.

 - Second of all, the currently computed hash is actually dependent on the document rotation. With named destinations, the fetched internal destination array is rotational invariant (as it should be), but this will not hold in general for the hash. We can easily avoid this issue by using a stringified destination array.

 - Third of all, note that according to the PDF specification[1], `GoToR` destinations may actually contain explicit destination arrays. Since we cannot really construct a hash in `annotation.js`, we currently have no good way to support those. Even though this case seems *very* rare in practice (I've not actually seen such a PDF file), it's in the specification, and this patch allows us to support that for "free".

---
[1] http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G11.1951685
2016-05-21 14:14:07 +02:00
.github Add an ISSUE_TEMPLATE 2016-03-23 22:48:14 +01:00
docs Convert all node make instances to gulp 2016-03-04 20:30:36 +01:00
examples Better components examples. 2016-04-28 13:30:03 -05:00
extensions Moves DEFAULT_PREFENCES into JSON format. 2016-05-11 17:58:17 -05:00
external Enables debugger only when needed. 2016-05-09 18:18:43 -05:00
l10n Update l10n files 2016-04-19 13:32:25 +02:00
src [api-minor] Let LinkAnnotation/PDFLinkService_getDestinationHash return a stringified version of the destination array for explicit destinations 2016-05-21 14:14:07 +02:00
test [api-minor] Let LinkAnnotation/PDFLinkService_getDestinationHash return a stringified version of the destination array for explicit destinations 2016-05-21 14:14:07 +02:00
web [api-minor] Let LinkAnnotation/PDFLinkService_getDestinationHash return a stringified version of the destination array for explicit destinations 2016-05-21 14:14:07 +02:00
.editorconfig Uses editorconfig to maintain consistent coding styles 2015-11-14 07:32:18 +05:30
.gitattributes Fixing C++,PHP and Pascal presence in the repo 2015-10-29 13:03:51 -05:00
.gitignore Added svg export tool 2014-08-14 23:18:19 +05:30
.gitmodules Update fonttools location and version (issue 6223) 2015-07-17 12:51:09 +02:00
.jshintignore Remove mozcentral test files. 2015-11-11 15:54:17 -06:00
.jshintrc Adds UMD headers to core, display and shared files. 2015-12-15 13:24:39 -06:00
.travis.yml Introducing gulp. 2016-03-04 09:36:46 -06:00
AUTHORS Adding to authors 2015-11-06 18:52:27 -07:00
gulpfile.js Moves DEFAULT_PREFENCES into JSON format. 2016-05-11 17:58:17 -05:00
LICENSE cleaned whitespace 2015-02-17 11:07:37 -05:00
make.js Remove unused variables 2016-05-11 16:11:13 +02:00
package.json Port the publish target to Gulp 2016-04-27 12:54:57 +02:00
pdfjs.config Release of 1.5.188 2016-04-21 15:11:26 -05:00
README.md Update link to CONTRIBUTING.md 2016-05-07 00:10:36 -04:00

README.md

PDF.js

PDF.js is a Portable Document Format (PDF) viewer that is built with HTML5.

PDF.js is community-driven and supported by Mozilla Labs. Our goal is to create a general-purpose, web standards-based platform for parsing and rendering PDFs.

Contributing

PDF.js is an open source project and always looking for more contributors. To get involved checkout:

For further questions or guidance feel free to stop by #pdfjs on irc.mozilla.org.

Getting Started

Online demo

Browser Extensions

Firefox and Seamonkey

PDF.js is built into version 19+ of Firefox, however the extension is still available:

  • Development Version - This version is updated every time new code is merged into the PDF.js codebase. This should be quite stable but still might break from time to time. This version is also reported to work when installed as extension in Seamonkey 2.39.

Chrome

  • The official extension for Chrome can be installed from the Chrome Web Store. This extension is maintained by @Rob--W.
  • Build Your Own - Get the code as explained below and issue gulp chromium. Then open Chrome, go to Tools > Extension and load the (unpackaged) extension from the directory build/chromium.

Getting the Code

To get a local copy of the current code, clone it using git:

$ git clone git://github.com/mozilla/pdf.js.git
$ cd pdf.js

Next, install Node.js via the official package or via nvm. You need to install the gulp package globally (see also gulp's getting started):

$ npm install -g gulp-cli

If everything worked out, install all dependencies for PDF.js:

$ npm install

Finally you need to start a local web server as some browsers do not allow opening PDF files using a file:// URL. Run

$ gulp server

and then you can open

It is also possible to view all test PDF files on the right side by opening

Building PDF.js

In order to bundle all src/ files into two productions scripts and build the generic viewer, issue:

$ gulp generic

This will generate pdf.js and pdf.worker.js in the build/generic/build/ directory. Both scripts are needed but only pdf.js needs to be included since pdf.worker.js will be loaded by pdf.js. If you want to support more browsers than Firefox you'll also need to include compatibility.js from build/generic/web/. The PDF.js files are large and should be minified for production.

Using PDF.js in a web application

To use PDF.js in a web application you can choose to use a pre-built version of the library or to build it from source. We supply pre-built versions for usage with NPM and Bower under the pdfjs-dist name. For more information and examples please refer to the wiki page on this subject.

Learning

You can play with the PDF.js API directly from your browser through the live demos below:

The repo contains a hello world example that you can run locally:

For an introduction to the PDF.js code, check out the presentation by our contributor Julian Viereck:

You can read more about PDF.js here:

Even more learning resources can be found at:

Questions

Check out our FAQs and get answers to common questions:

Talk to us on IRC:

  • #pdfjs on irc.mozilla.org

Join our mailing list:

Subscribe either using lists.mozilla.org or Google Groups:

Follow us on twitter: @pdfjs

Weekly Public Meetings