使用pdfviewer.js滚动时,巨大的PDF需要时间来渲染

时间:2017-05-16 07:14:37

标签: javascript pdf pdf-viewer pdfjs

我有自定义pdf viewer html页面来呈现pdf。我正在使用pdfjs库来渲染pdf。它对我来说很好。

当我打开小pdf文件时,它会下载并快速呈现文件, 当我打开大PDF时,它会快速下载pdf文件,但渲染pdf文件需要花费太多时间。

我可以看到大型pdf文件内容但是当我向下滚动时它会挂起整个浏览器。

有什么建议吗?

2 个答案:

答案 0 :(得分:1)

总结你的OP - 由于你没有回答问题或提供PDF的例子,你遇到了麻烦,没有人可以给出一个确定的答案。这是一种耻辱,因为设置一个片段来探测问题很容易。

我猜想,PDF文件的内容与pdfjs的功能之间可能存在不匹配。如果我们有你的示例文件,我们可能会在developers git,上引发一个似乎是活跃且受到良好支持的错误。

以下是对创建PDF呈现引擎所涉及问题的高级描述,旨在说明您可能希望坚持使用流行浏览器中提供的主流内置呈现引擎的原因。

渲染PDF是一项复杂的任务。如果将其分解为组件操作是可行的,但有几个级别的PDF标准引入了大量选项。很可能你的PDF包含了pdfjs中有错误的渲染实现的东西,或者pdfjs在尝试渲染它时会窒息的东西。

一些背景:PDF格式同时也是辉煌和恶魔。由于其便携性而非常出色,但由于内部结构和存储机制的恶魔。没有友好的DOM' DOM'和HTML一样。如果我们重新开始开发便携式文档格式,那么我们不会选择PDF格式。但是PDF目前有太多的动力被抛弃,期间。

要呈现'将PDF文件的内容发送到显示设备或打印机,您的代码需要解压缩PDF并将组件(图像,格式化文本,页面)渲染到显示设备。这对任何有HTML DOM操作经验的人来说都是直截了当的,但没有直接比较。

PDF是一种vector-based graphics定义语言。最有可能与大多数人相同的是SVG。

PDF文件中不是嵌入图像的任何内容都是基于矢量的输出,除了由x / y坐标而不是连续字符串进行拉链压缩和布局的文本。

绘图和布局指令存在于通过像树这样的指针链接的部分(摘要)中 - 没有简单的从上到下的读取和放大。渲染过程。 PDF可以包含冗余部分,替换为稍后编辑但仍然存在。而在此主题上,除非PDF文件配置为快速Web查看,否则呈现引擎必须等待整个文件传递,然后才能理解如何显示它。快速的网络视图使'索引'和页面1部分位于文件流的顶部,以允许渲染引擎尽快将某些内容输出到屏幕。

为了充分支持PDF,您必须能够呈现PDF包含的任何内容并完美地按照PDF标准执行此操作,否则您可能会发现PDF查看器崩溃或无法呈现整个PDF。您必须满足各种Acrobat标准级别,以及编辑包(Word,Illustrator,InDesign)供应商插入PDF文件的快捷方式和膨胀;图层,缩略图等

在PDF中,文本可以存储为矢量绘图说明'或'引用字体文件中的字符(如HTML文本)。

关于颜色,请阅读PDF规范,您将看到原始PDF制作人可以决定使用的颜色空间选项数组。其中一些是用于使用外来颜色机制的打印设备。您必须在屏幕上将这些解释为合理的设备颜色。

然后是字体。字体可能是嵌入的子集,也可能不是。如果渲染引擎运行时PDF中提到的字体不存在,则必须决定使用哪种替代字体。为了保持PDF的逼真度,您需要在PDF中定义的比例下将字形实现为绘图表面上的矢量图形。

鉴于PDF中的分层,缩放和旋转功能,您可能会将html画布视为绘图表面。任何知道的人都会告诉你,在画布世界里,你几乎都是自己渲染函数 - 画布的优点和缺点,但是对于渲染PDF你可能需要绝对控制,所以大多数库都不会是用到你。这意味着您正在使用绘制原语,这需要时间并且容易受到错误的影响。

您面临的最大挑战可能是了解您必须做的全部范围和范围。这不是不可能,但很难。

总结本讲座关于编写PDF渲染引擎的挑战 - 完美呈现PDF文件是一项非常复杂的任务。如果在早期发布阶段这样的产品在不支持PDF规范的块方面感觉非常错误,那就不足为奇了。不要对开发者太过刻薄 - 他们的目标很难。如果开发人员有支持并因此有时间留在项目中,那么PDF规范中的全套功能可能会在某个时间点覆盖在他们的产品中。理想情况下,他们会发布不受支持的PDF功能列表,以便用户可以识别潜在的问题,但是在PDF文件在渲染或引擎崩溃时看起来很奇怪之前,您永远不会真正知道存在问题。

答案 1 :(得分:0)

这似乎是您使用旧版本的PDF.js,请尝试使用较新版本