Having pdf.js available on a public cdn can simplify installation and update workflows in some cases.
cdnjs will likely host pdf.js for free if was ask them to.
collinanderson
All 29 comments
please explain what problem it will fix. "because other projects do it" is a bad reason.
yurydelendik
on 17 Nov 2014
Good point. I updated the title and description.
collinanderson
on 17 Nov 2014
pdf.js library is installable from npm using npm install pdfjs-dist, via bower install pdfjs-dist and simply via git pull from pdfjs-dist repo.
Having pdf.js available on a public cdn can simplify installation and update workflows in some cases.
What case is discussed here?
yurydelendik
on 17 Nov 2014
In my workflow, I don't use npm or bowar or any tool for front-end dependency management and I prefer not to vendor copies of any library.
I instead link to a cdn-hosted version of jquery, jqueryui, ckeditor, or any other javascript library I need. Whenever I need to "upgrade", I simply change the version number in the url.
collinanderson
on 17 Nov 2014
I instead link to a cdn-hosted version
Defects in browsers and CORS policies does not let users to instantiate web worker (pdf.worker.js file) that performs actual PDF parsing and significantly improves performance of the PDF.js.
There is an alternative: disable the worker. But that delivers sub-par performance and we don't want to advertise that.
yurydelendik
on 17 Nov 2014
That's a good reason. Would be nice to get it CDN hosted if CORS ever allows it. Thanks!
collinanderson
on 17 Nov 2014
I stumbled upon this when trying to use PDF.js in a jsfiddle.
nschloe
on 23 Mar 2015
Yup, mostly when using a prototyping tool without wanting to install a bunch of npm libraries locally
joallard
on 6 Apr 2015
:+1: for cdn support. Great for sharing bug repros and also quick prototyping
luisrudge
on 12 Aug 2015
Why there is still no CDN support as of November 2015?
lony
on 2 Nov 2015
Why there is still no CDN support as of November 2015?
AFIAK @cdnjs is publishing PDF.js (e.g. https://github.com/cdnjs/cdnjs/pull/5993)
it is not this repository contributors initiative, so we are not aware if there is any issues present in relation with the published code.
yurydelendik
on 2 Nov 2015
Sorry then, maybe it is vice to add the URL to the ReadMe to avoid further questions?
lony
on 2 Nov 2015
Sorry then, maybe it is vice to add the URL to the ReadMe to avoid further questions?
Only when we will verify that it works without issues or security risks. See my concern above at https://github.com/mozilla/pdf.js/issues/5490#issuecomment-63322602
yurydelendik
on 2 Nov 2015
Sorry then :)
lony
on 2 Nov 2015
My use case requires complete transparency. Performance is entirely subordinate. That's why I use pdf.js because I want nothing hidden away on a server. Everything is done on the client, the code is guaranteed to do what it claims it does.
My own code is small, easy to read and open for scrutiny. Never minified even in production. I rely on third-party code that runs on the client, and the trust stems from the authors and the open source community. The app is open source on git hub and the app itself is even hosted on git hub.
As long as the app is kept this way, my credibility is not important. However, if I include pdf.js in the source, even if it is not built or minified, that seriously degrades transparency. The user needs to have faith in me that I have not hidden malicious code in the pdf.js jungle.
On the other hand, if pdf.js and all other third-party code, were fetched (preferably unminified) from a cdn endorsed by the team and community, my own credibility becomes nearly irrelevant.
camitz
on 30 Dec 2015
With wrapped for the worker (see #6753), the core library is "hostable" on CDN, e.g. minimal example that works fine on the jsfiddle and jsbin:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<title>Minimal PDF.js example</title>
<script src="//mozilla.github.io/pdf.js/build/pdf.js"></script>
</head>
<body>
<script>
var loadingTask = PDFJS.getDocument('//cdn.mozilla.net/pdfjs/tracemonkey.pdf');
loadingTask.promise.then(function (pdfDocument) {
console.log('Num pages: ' + pdfDocument.numPages);
}, function (reason) {
console.error('Loading Error: ' + reason);
})
</script>
</body>
</html>
NPM CDN hosts all npm packages on request.
https://npmcdn.com/[email protected]/build/pdf.combined.js
Obviously not maintainer sanctioned, but it's there if people want it for prototyping purposes.
darylteo
on 18 Feb 2016
@yurydelendik That will definitely work for me, thanks!
@darylteo Thanks for the tip. Not as transparent though, which is the which would be the whole point for me.
camitz
on 18 Feb 2016
@darylteo, PDF.js team is always thinking about deprecating pdf.combined.js since it is not intended use of the library. Please try to not use it when it's possible (as well as do not apply disableWorker=true, which pdf.combined.js implies).
yurydelendik
on 18 Feb 2016
@yurydelendik thanks for the info! I'm just building a prototype to workaround iOS WKWebView not rendering PDFs properly in iframes for the time being but will keep that in mind.
darylteo
on 19 Feb 2016
@camitz , I'm curious. How or why did yurydelendik's Feb 8 code "work for [you]"? I am asking because it references //mozilla.github.io/pdf.js/build/pdf.js, and I wouldn't generally view that as a cdn. And, it also isn't referencing a versioned copy of pdf.js
@yurydelendik (or whomever is appropriate) - can this issue please be reopened until versioned and minified copies of pdf.js are definitely available on at least one reputable cdn? This issue started with a reference to cdnjs, and as per their website, they now have a preferred way to "Request a lib" via a GitHub issue template for requesting that PDF.js is added to cdnjs. Would a PDF.js project leader please make such a request? (I would do it myself but I don't know whether the PDF.js project would want cdnjs to use pdf.js or pdfjs-dist. Also, it would probably be best if the PDF.js project itself created a minified version of its code that goes to cdnjs.)
I think that camitz's use case that he shared on Dec 30 is very good and still applicable for lots of people (including myself). Like camitz, I would like to minimize the amount of trust that my users have to put in me, and using copies of libraries that are on a CDN definitely helps with that.
jon-freed
on 16 Apr 2016
@jon-freed There is https://npmcdn.com/pdfjs-dist which is up-to-date. For cdnjs there is the pull request https://github.com/cdnjs/cdnjs/pull/5993. I don't think there is more we can do at this point; especially the npmcdn website is nice because it uses our NPM package and is therefore always up-to-date.
timvandermeij
on 16 Apr 2016
@jon-freed here is jsfiddle example that uses npmcdn https://jsfiddle.net/y3rsLwwp/5/
yurydelendik
on 16 Apr 2016
@timvandermeij , @yurydelendik : Thank you for that information! That helps clarify (to me, anyhow) what darylteo stated on Feb 17
jon-freed
on 16 Apr 2016
hmmmm ... CDNJS maintain here, I'll work on it now.
PeterDaveHello
on 18 Jun 2016
Okay, now added in: https://github.com/cdnjs/cdnjs/commit/df40a0dd137d5ed1e885354ca8ac492df20bcac0
PeterDaveHello
on 18 Jun 2016
PeterDaveHello
on 18 Jun 2016
@PeterDaveHello Awesome! Good to have PDF.js hosted on two CDNs (cdnjs and npmcdn) now.
timvandermeij
on 18 Jun 2016
No probs. Just FYI, by the architecture, npmcdn may update a little bit faster, but CDNJS will have better performance for production environment, and CDNJS also provides minified files and additional map files.
PeterDaveHello
on 18 Jun 2016
Related issues
SehyunPark
·
3Comments
aaronshaf
·
3Comments
xingxiaoyiyio
·
3Comments
THausherr
·
3Comments
brandonros
·
3Comments
Most helpful comment
:+1: for cdn support. Great for sharing bug repros and also quick prototyping