f05e5c5460
The reason for the bug is that we're only computing a checksum of the image data itself, but completely ignore the inline dictionary. The latter is important, since in practice it's not uncommon for inline images to be identical but use e.g. different ColourSpaces. There's obviously a couple of different ways that we could compute a hash/checksum of the dictionary. Initially I tried using `MurmurHash3_64` to compute a hash of the keys/values in the dictionary. Unfortunately this approach turned out to be *way* too slow in practice, especially for PDF files with a huge number of inline images; in particular issue 2618 would regresses quite badly with this solution. The solution that is instead implemented in this patch, is to compute a checksum of the dictionary contents. While this is a much simpler, not to mention a lot more efficient, solution there's one drawback associated with it: If the contents of inline image dictionaries are ordered differently, they will not be considered equal with this approach which could thus lead to failures to cache repeated inline images. In practice this doesn't seem to be a problem in any of the PDF files I've tested, and generally I'd rather err on the side of *not* caching given that too aggressive caching can easily lead to rendering bugs. One small, but somewhat annoying, complication is that by the time `Parser.makeInlineImage` is called, we no longer know the *exact* stream position where the inline image dictionary starts. Having access to that information is crucial here, and the easiest solution I could come up with is to track this in the current `Lexer` instance.[1] With the patch, we're thus able to fix the referenced issues without incurring large regressions in problematic cases such as issue 2618. Fixes 9398; also improves/fixes the `issue8823` reference test. --- [1] Obviously I'd have preferred if this patch could be limited to `Parser.makeInlineImage`, without the need for this "hack", but I'm not sure what that'd look like here.
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, visit:
- Issue Reporting Guide
- Code Contribution Guide
- Frequently Asked Questions
- Good Beginner Bugs
- Projects
Feel free to stop by #pdfjs on irc.mozilla.org for questions or guidance.
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.
-
Please note that the extension is not guaranteed to be compatible with Firefox versions that are older than the current Nightly version, see the Release Calendar.
-
The extension may also work in Seamonkey, provided that it is based on a Firefox version as above (see Which version of Firefox does SeaMonkey 2.x correspond with?), but we do not guarantee compatibility.
-
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 toTools > Extensionand load the (unpackaged) extension from the directorybuild/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:
Please keep in mind that this requires an ES6 compatible browser; refer to Building PDF.js for usage with older browsers.
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 production scripts and build the generic
viewer, run:
$ 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. 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.
Including via a CDN
PDF.js is hosted on several free CDNs:
- https://www.jsdelivr.com/package/npm/pdfjs-dist
- https://cdnjs.com/libraries/pdf.js
- https://unpkg.com/pdfjs-dist/
Learning
You can play with the PDF.js API directly from your browser using the live demos below:
The repository contains a hello world example that you can run locally:
More examples can be found in the examples folder. Some of them are using the pdfjs-dist package, which can be built and installed in this repo directory via gulp dist-install command.
For an introduction to the PDF.js code, check out the presentation by our contributor Julian Viereck:
More learning resources can be found at:
Questions
Check out our FAQs and get answers to common questions:
Talk to us on IRC (Internet Relay Chat):
- #pdfjs on irc.mozilla.org
File an issue:
Follow us on twitter: @pdfjs