Go to file

Jonas Jenwald 2f3805efbc Switch to using ESLint, instead of JSHint, for linting Please note that most of the necessary code adjustments were made in PR 7890. ESLint has a number of advantageous properties, compared to JSHint. Among those are: - The ability to find subtle bugs, thanks to more rules (e.g. PR 7881). - Much more customizable in general, and many rules allow fine-tuned behaviour rather than the just the on/off rules in JSHint. - Many more rules that can help developers avoid bugs, and a lot of rules that can be used to enforce a consistent coding style. The latter should be particularily useful for new contributors (and reduce the amount of stylistic review comments necessary). - The ability to easily specify exactly what rules to use/not to use, as opposed to JSHint which has a default set. Note: in future JSHint version some of the rules we depend on will be removed, according to warnings in http://jshint.com/docs/options/, so we wouldn't be able to update without losing lint coverage. - More easily disable one, or more, rules temporarily. In JSHint this requires using a numeric code, which isn't very user friendly, whereas in ESLint the rule name is simply used instead. By default there's no rules enabled in ESLint, but there are some default rule sets available. However, to prevent linting failures if we update ESLint in the future, it seemed easier to just explicitly specify what rules we want. Obviously this makes the ESLint config file somewhat bigger than the old JSHint config file, but given how rarely that one has been updated over the years I don't think that matters too much. I've tried, to the best of my ability, to ensure that we enable the same rules for ESLint that we had for JSHint. Furthermore, I've also enabled a number of rules that seemed to make sense, both to catch possible errors and various style guide violations. Despite the ESLint README claiming that it's slower that JSHint, https://github.com/eslint/eslint#how-does-eslint-performance-compare-to-jshint, locally this patch actually reduces the runtime for `gulp` lint (by approximately 20-25%). A couple of stylistic rules that would have been nice to enable, but where our code currently differs to much to make it feasible: - `comma-dangle`, controls trailing commas in Objects and Arrays (among others). - `object-curly-spacing`, controls spacing inside of Objects. - `spaced-comment`, used to enforce spaces after `//` and `/*. (This is made difficult by the fact that there's still some usage of the old preprocessor left.) Rules that I indend to look into possibly enabling in follow-ups, if it seems to make sense: `no-else-return`, `no-lonely-if`, `brace-style` with the `allowSingleLine` parameter removed. Useful links: - http://eslint.org/docs/user-guide/configuring - http://eslint.org/docs/rules/		2016-12-16 21:06:36 +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	Widget annotation: implement field name according to the specification	2016-11-02 21:44:44 +01:00
extensions	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01:00
external	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01:00
l10n	Update l10n files	2016-12-05 10:10:17 +01:00
src	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01:00
test	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01:00
web	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01:00
.editorconfig	Uses editorconfig to maintain consistent coding styles	2015-11-14 07:32:18 +05:30
.eslintignore	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01:00
.eslintrc	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +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	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01:00
LICENSE	cleaned whitespace	2015-02-17 11:07:37 -05:00
make.js	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01:00
package.json	Switch to using ESLint, instead of JSHint, for linting	2016-12-16 21:06:36 +01: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

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

https://mozilla.github.io/pdf.js/web/viewer.html

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 ESR version, see the Release Calendar.
- The extension should 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 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

http://localhost:8888/web/viewer.html

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

http://localhost:8888/test/pdfs/?frame

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.