在某些情况下,在公共CDN上提供pdf.js可以简化安装和更新工作流程。
如果要求cdnjs可能会免费托管pdf.js。
请说明它将解决的问题。 “因为其他项目做到了”是一个不好的理由。
好点子。 我更新了标题和描述。
可以从npm使用npm install pdfjs-dist
,通过bower install pdfjs-dist
以及通过pdfjs-dist回购中的git pull来安装pdf.js库。
在某些情况下,在公共CDN上提供pdf.js可以简化安装和更新工作流程。
这里讨论什么情况?
在我的工作流程中,我不使用npm或bowar或任何用于前端依赖项管理的工具,而且我不希望提供任何库的供应商副本。
我改为链接到cdn托管的jquery,jqueryui,ckeditor或我需要的任何其他JavaScript库的版本。 每当需要“升级”时,我只需更改URL中的版本号即可。
我改为链接到CDN托管的版本
浏览器中的缺陷和CORS策略不允许用户实例化执行实际PDF解析并显着提高PDF.js性能的Web worker(pdf.worker.js文件)。
还有一种选择:禁用工作进程。 但这提供了低于标准的性能,我们不想宣传它。
那是一个很好的理由。 如果CORS允许,最好将它托管在CDN上。 谢谢!
尝试在jsfiddle中使用PDF.js时,我偶然发现了这一点。
是的,主要是在使用原型工具而又不想在本地安装一堆npm库时
:+1:支持CDN。 非常适合共享bug复制和快速原型制作
为什么截至2015年11月仍不提供CDN支持?
为什么截至2015年11月仍不提供CDN支持?
AFIAK @cdnjs正在发布PDF.js(例如https://github.com/cdnjs/cdnjs/pull/5993)
这不是此存储库贡献者的主动性,因此我们不知道是否存在与已发布代码有关的问题。
抱歉,将URL添加到自述文件以避免其他问题可能是罪恶的做法?
抱歉,将URL添加到自述文件以避免其他问题可能是罪恶的做法?
只有在我们确认它可以正常工作而没有问题或安全风险的情况下。 请参阅上面我对https://github.com/mozilla/pdf.js/issues/5490#issuecomment -63322602的关注
那不好意思了 :)
我的用例需要完全透明。 性能是完全从属的。 这就是为什么我使用pdf.js的原因,因为我不想在服务器上隐藏任何内容。 一切都在客户端上完成,保证代码可以执行其声明的工作。
我自己的代码很小,易于阅读且易于审查。 即使在生产中也从未缩小。 我依靠在客户端上运行的第三方代码,信任来自作者和开源社区。 该应用程序是git hub上的开源软件,而该应用程序本身甚至托管在git hub上。
只要应用程序保持这种方式,我的信誉就不重要。 但是,如果我在源代码中包含pdf.js,即使未构建或缩小它,也会严重降低透明度。 用户需要相信我,我没有在pdf.js丛林中隐藏恶意代码。
另一方面,如果pdf.js和所有其他第三方代码是从团队和社区认可的CDN中获取的(最好是未缩编的),那么我自己的可信度就变得无关紧要了。
通过为工作者包装(请参阅#6753),核心库在CDN上是“可托管的”,例如,最小示例在jsfiddle和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可应要求托管所有npm软件包。
https://npmcdn.com/[email protected]/build/pdf.combined.js
显然,维护者没有批准它,但是如果人们希望将其用于原型设计,就可以在这里找到它。
@yurydelendik那绝对对我
@darylteo感谢您的提示。 但是不那么透明,这对我来说就是重点。
@darylteo ,PDF.js团队一直在考虑弃用pdf.combined.js,因为它不打算用于该库。 请尽量不要使用它(以及不要应用disableWorker = true,这意味着pdf.combined.js的含义)。
@yurydelendik感谢您的信息! 我只是建立一个可解决iOS WKWebView的原型,暂时无法在iframe中正确呈现PDF,但请牢记这一点。
@camitz ,我很好奇。 yurydelendik 2月8日的代码如何或为什么“为[您]工作”? 我问是因为它引用//mozilla.github.io/pdf.js/build/pdf.js,而且我一般不会将其视为CDN。 而且,它也没有引用pdf.js的版本副本
@yurydelendik (或适当的任何人)-可以在至少一个信誉良好的CDN上肯定有pdf.js的版本和缩小副本之前重新打开此问题? 此问题始于对cdnjs的引用,根据他们的网站,现在,他们有一种首选方法,可以通过GitHub问题模板“请求lib”来请求将PDF.js添加到cdnjs。 PDF.js项目负责人是否可以提出这样的请求? (我会自己做,但我不知道PDF.js项目是否希望cdnjs使用pdf.js或pdfjs-dist。而且,如果PDF.js项目本身创建了的缩小版本,则可能是最好的选择。它的代码转到cdnjs。)
我认为他12月30日分享的camitz用例非常好,仍然适用于很多人(包括我自己)。 像camitz一样,我想最大程度地减少用户对我的信任,并且使用CDN上的库副本肯定会有所帮助。
@ jon-freed这是最新的https://npmcdn.com/pdfjs-dist 。 对于cdnjs,有拉请求https://github.com/cdnjs/cdnjs/pull/5993。 我认为目前我们还不能做更多的事情。 特别是npmcdn网站非常好,因为它使用了我们的NPM软件包,因此始终是最新的。
@ jon-freed是使用npmcdn https://jsfiddle.net/y3rsLwwp/5/的jsfiddle示例
@ timvandermeij , @ yurydelendik :谢谢您提供的信息! 这有助于弄清(无论如何对我而言)达里尔泰奥在2月17日所说的话
嗯... CDNJS在这里维护,我现在就处理。
好的,现在添加到: https :
请参阅: https :
@PeterDaveHello太棒了! 很高兴现在将PDF.js托管在两个CDN(cdnjs和npmcdn)上。
没有问题。 仅就FYI而言,通过该体系结构,npmcdn的更新速度可能会快一点,但是CDNJS在生产环境中将具有更好的性能,并且CDNJS还提供了缩小的文件和其他映射文件。
最有用的评论
:+1:支持CDN。 非常适合共享bug复制和快速原型制作