Go to file
Jonas Jenwald 9eb9065c79 Ensure that we use the *correct* paintedViewport in PDFPageView.cssTransform, to avoid visual glitches on quick rotations (PR 7738 follow-up)
*This fixes a regression from commit c9a0955c9c, i.e. PR 7738.*

Currently if you quickly rotate a document at least *twice*,[1] such that rendering of a page hasn't finished for the first rotation before the last rotation is triggered, the `cssTransform` method can fail to update the page correctly leading to it looking temporarily distorted.

The reason why things break is that previously we stored the `viewport` on the canvas DOM element, meaning that when it was accessed in `cssTransform` is was guaranteed to point to the `viewport` of the `zoomLayer` canvas.
Generally you want to avoid storing data on DOM elements this way, and during the `PDFPageView` refactoring needed to support SVG rendering, the previous `viewport` was instead stored directly on `PDFPageView`.
However, the problem is first of all that the `paintedViewport` only stores the *last* `viewport` computed, and second of all that there're no guarantees that it actually applies to the current `zoomLayer` canvas.
If a document is rotated slowly enough that rendering finishes *before* the next rotation then this problem doesn't exist, but for sufficiently quick rotations rendering will be cancelled at least once and the `paintedViewport` could thus be bogus.

The solution for the above problems is to ensure that we track the correct `viewport` for each DOM element (canvas or svg),[2] which seemed easist to do with a `WeakMap`.[3]

---
[1] I'm able to reproduce this using the `tracemonkey` file, but please note that for pages with few operations, i.e. that render very quickly, the effect may be hard to spot.

[2] One other possible solution that I briefly considered, was to wait until rendering finished before storing the current `viewport`. However, that would have caused issues with rotating a page before the *first* rendering operation had finished.

[3] This regression took me way longer to both figure out, and fix, than I'd like to admit :-)
2017-01-23 12:13:53 +01:00
.github Add an ISSUE_TEMPLATE 2016-03-23 22:48:14 +01:00
docs Github -> GitHub 2016-05-26 11:11:50 -07:00
examples Remove globals that are now unnecessary thanks to the use of various ESLint environments (e.g. Node, ShellJS, Jasmine) 2016-12-16 21:09:55 +01:00
extensions Adjust the space-unary-ops ESLint rule to comply with mozilla-central lint rules 2017-01-16 17:19:25 +01:00
external Add the external/builder/fixtures/ directory to .eslintignore, to avoid having to disable various lint rules locally 2017-01-10 14:45:40 +01:00
l10n Update l10n files 2017-01-16 09:54:50 +01:00
src Merge pull request #7973 from Snuffleupagus/eslint_spaced-comment 2017-01-22 21:58:42 +01:00
test Merge pull request #7904 from Snuffleupagus/issue-7901 2017-01-12 21:55:57 +01:00
web Ensure that we use the *correct* paintedViewport in PDFPageView.cssTransform, to avoid visual glitches on quick rotations (PR 7738 follow-up) 2017-01-23 12:13:53 +01:00
.editorconfig Uses editorconfig to maintain consistent coding styles 2015-11-14 07:32:18 +05:30
.eslintignore Add the external/builder/fixtures/ directory to .eslintignore, to avoid having to disable various lint rules locally 2017-01-10 14:45:40 +01:00
.eslintrc Merge pull request #7973 from Snuffleupagus/eslint_spaced-comment 2017-01-22 21:58:42 +01:00
.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
.travis.yml Travis CI: use most recent version of NPM 2016-10-27 21:10:19 +02:00
AUTHORS Adding to authors 2015-11-06 18:52:27 -07:00
gulpfile.js Moves locale and cmaps tasks to gulpfile. 2017-01-10 11:50:38 -06:00
LICENSE cleaned whitespace 2015-02-17 11:07:37 -05:00
make.js Enable the spaced-comment ESLint rule 2017-01-19 16:41:59 +01:00
package.json Moves locale and cmaps tasks to gulpfile. 2017-01-10 11:50:38 -06:00
pdfjs.config Release of 1.6.210 2016-10-04 12:19:51 -05:00
README.md Add HTTPS support 2016-11-04 15:55:56 +01:00

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 one extension is still available:

  • Development Version - This extension is mainly intended for developers/testers, and it is updated every time new code is merged into the PDF.js codebase. It should be quite stable, but might break from time to time.

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