Please add support for systemjs.
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
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'));
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:
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.
timvandermeij
on 8 Jan 2016
I also recommend to override module format when using jspm: jspm install npm:pdfjs-dist -o "{format: 'amd'}"
yurydelendik
on 4 Apr 2016
Related issues
Snuffleupagus
·
28Comments
oddjobz
·
46Comments
collinanderson
·
29Comments
kaymes
·
62Comments
snorp
·
95Comments