Pdf.js: Support Systemjs

Created on 22 Dec 2015 · 34Comments · Source: mozilla/pdf.js

Please add support for systemjs.

2-feature

Source

Vanuan

All 34 comments

I would request more information since no examples are provided. And I think Browserify works with pdfjs-dist currently (with some modules exceptions).

yurydelendik on 22 Dec 2015

Here's the most common example to use systemjs:

npm install jspm
jspm init # use defaults
jspm install pdfjs-dist

index.html

<!DOCTYPE html>
<html lang="en-us">

<head>
<meta charset="utf-8">
<title>Title</title>
</head>

<body>
    <script src="jspm_packages/system.js"></script>
    <script src="config.js"></script>
    <script>
      System.import('src/app.js');
    </script>
</body>
</html>

src/app.js

# ES6 syntax
import pdfjs from 'pdfjs-dist';

# expected pdfjs to be a window.PDFJS object

Vanuan on 22 Dec 2015

Thank you for example

yurydelendik on 22 Dec 2015

In previous versions we could use jspm shim to use pdfjs.
https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm
But after inclusion of node-ensure, we can't (node-ensure doesn't seem to be compatible with system.js).

Vanuan on 22 Dec 2015

Actually, this is a request for jspm packager, not specifically Systemjs loader.
I.e. it would be fine if it would require jspm shim, but don't add incompatible changes like node-ensure.

Vanuan on 22 Dec 2015

@Vanuan

Having the following in the config.js workaround the issue:

    "npm:[email protected]": {
      "process": "github:jspm/[email protected]",
      "node-ensure": "empty",
      "entry?name=[hash]-worker.js": "empty"
    },

(empty is a empty.js file with no content)

Similar hack is need for Browserify

yurydelendik on 22 Dec 2015

Now issue: pdf.worker.js is loaded twice, that's an issue was solved by request.ensure() in webpack. The './pdf.worker.js' has to be forbidden from loading until it's really needed.

yurydelendik on 22 Dec 2015

I thought "PDFJS.disableWorker = true;" solves that? Isn't it?

Vanuan on 22 Dec 2015

If you use System.import('./pdf.worker'), it will issue only one http request.

Or even System.import('pdfjs-dist/build/pdf.worker')

Is there a specific reason why node-ensure was used? I believe System loader works fine in Webpack.

Vanuan on 22 Dec 2015

"PDFJS.disableWorker = true;" is not an option,since we want to move PDF processing on the different thread. We don't want suggest lousy solution for library users, do we?

yurydelendik on 22 Dec 2015

Well, I'd be prefer lousy solution than no solution at all. For my use case, even 1 second page freeze is fine.
I'd be glad if you find a better solution.

Vanuan on 22 Dec 2015

Is there a specific reason why node-ensure was used?

If you look carefully at what examples/webpack/ produces:

pdf.js yury$ ls -la build/webpack/
total 2384
drwxr-xr-x   5 yury  staff     170 Dec 22 15:20 .
drwxr-xr-x  34 yury  staff    1156 Dec 22 10:08 ..
-rw-r--r--   1 yury  staff  546125 Dec 21 16:35 1.bundle.js
-rw-r--r--   1 yury  staff  546463 Dec 21 16:35 9d074593b165291f150e-worker.js
-rw-r--r--   1 yury  staff  122796 Dec 21 16:35 bundle.js

"bundle.js" is main file that loads (that means it will bring and initialize UI after 122796 bytes -- faster page start up). "9d074593b165291f150e-worker.js" is a worker which will run the logic and don't lock UI on slow devices. "1.bundle.js" portion is loaded only if disableWorker triggered and for legacy browsers such as IE9.

yurydelendik on 22 Dec 2015

I'd be glad if you find a better solution.

I'm expecting the systemjs might have some kinda guard to not parse all requires (replacing "./pdf.worker.js" with "empty" did not work for me).

@Vanuan Can you file an issue with systemjs to see if they have something better in mind? Thanks.

yurydelendik on 22 Dec 2015

Sounds like the very last issue at systemjs https://github.com/systemjs/systemjs/issues/983 ?

yurydelendik on 22 Dec 2015

Well, I'd be prefer lousy solution than no solution at all. For my use case, even 1 second page freeze is fine.

@Vanuan, nothing changed in usage of the pdf.combined.js file (I hope) -- looks like we need to keep it for such cases. You need to use it as you described as an issue in #6729. From your description it was not clear you are planing to use systemjs to load PDFJS.

yurydelendik on 22 Dec 2015

nothing changed in usage of the pdf.combined.js file

Ah, great!

Vanuan on 22 Dec 2015

Anyway, something has definitely changed with regard to using it with worker.
Previously, we could use full path to worker, but get Uncaught ReferenceError: require is not defined inside it:

PDFJS.workerSrc = 'jspm_packages/npm/[email protected]/build/pdf.worker.js';

Now, it seems like it's stuck on loading files. As if module loaded callback never completes.
The last module requested is process.

Probably, Systemjs can't process the following construction:

(function(process) {
  if (typeof PDFJS === 'undefined') {
    (typeof window !== 'undefined' ? window : this).PDFJS = {};
  }
})(require('process'));

Vanuan on 23 Dec 2015

👍1

Anyway, something has definitely changed with regard to using it with worker.
Previously, we could use full path to worker,

pdf.combined.js fully included/includes pdf.worker.js and does not need workerSrc to be specified.

yurydelendik on 23 Dec 2015

Changes to pdf.combined.js https://github.com/mozilla/pdfjs-dist/commit/a7cd5f77b00bac19c0f6ee4c2cfd5bbf0fe45d8f#diff-eccf5b94e31b0939738de07167e02af6

yurydelendik on 23 Dec 2015

Yeap, I'm just evaluating options of using workers along with jspm.

Vanuan on 23 Dec 2015

Now issue: pdf.worker.js is loaded twice, that's an issue was solved by request.ensure() in webpack

So, now it is being loaded in the main thread and doesn't use importScripts()?

Vanuan on 23 Dec 2015

My src/app.js is:

import pdfjs from 'pdfjs-dist';

console.log(PDFJS);

So it's not even using getDocument yet, but in network monitor it shows two entries for pdf.worker.js

yurydelendik on 23 Dec 2015

It's strange. I only see one entry.

Vanuan on 23 Dec 2015

It's strange. I only see one entry.

It shall be none AFAIK :)

yurydelendik on 23 Dec 2015

The same on Firefox and Chrome:
screen shot 2015-12-22 at 5 34 42 pm

yurydelendik on 23 Dec 2015

Ah. So looks like Systemjs dumbly parses all requires and tries to load them...

Vanuan on 23 Dec 2015

Conditional require is not a very common use case.

Vanuan on 23 Dec 2015

That's why it tries to load node-ensure too.

Vanuan on 23 Dec 2015

@yurydelendik
How such requires help webpack? Webpack still loads worker using importScripts, right?

Vanuan on 23 Dec 2015

Conditional require is not a very common use case.

I would disagree, https://github.com/systemjs/systemjs/issues/983 and https://github.com/webpack/docs/wiki/code-splitting are common use cases.

Webpack still loads worker using importScripts, right?

~~It does.~~ via new Worker(..). But it also has an option to load pdf.worker.js as module if workers are disabled.

yurydelendik on 23 Dec 2015

The issue will be solved by #6775 -- the systemjs has auto-detect for type of the module. Now it's commonjs, with UMD it will be AMD so it will not try to parse require().

P.S. wip at https://github.com/yurydelendik/pdf.js/tree/pdfjsumd

yurydelendik on 28 Dec 2015

Wow, great, I'll try as soon as merged and released.

Vanuan on 28 Dec 2015

Closing as fixed by #6825. If there are remaining problems, please open a new issue.