有很多 API 或 SDK 可供开发人员编写 PDF 转换器。PDFLib、TCPDF、DOMPDF 等
也有现成的 PDF 转换器，但它们没有我想要的所有选项。所以我认为最好只写我自己的转换器。
如果您自己使用 HTML 到 PDF 转换器，大约需要 10 分钟。需要多长时间？是否需要您在到达任何地方之前编写一个完整的 HTML 解析器？
我的应用程序所需的主要功能是具有自定义文档大小，以及包含文本和图像的绝对定位的 div。没有 iframe。
问问题
679 次
1 回答
3
以下是您可能应该如何考虑此任务的方式 - 您不是将 HTML 转换为 PDF，而是您正在编写一个将 HTML 渲染为 PDF 的渲染器。
因此，如果您没有 HTML 渲染器的外壳，那么这是您的第一步。它应该接受 HTML 并给定一个“窗口大小”将调用一组您实现的方法来呈现基元（绘制线条、放置图像、放置文本、放置链接等）。毫无疑问，您会遇到 HTML 页面没有固定高度而 PDF 页面有的问题。
接下来，您将需要一个体面的 PDF 后端。体面，我的意思是它不会在大量图像上爆炸，以理智的方式处理资源等等。它还应该具有合理的 Unicode 支持，因此如果您向其发送 Unicode 字符串，它会自动执行 PDF 机制以正确呈现它，因此您不必手动执行该工作（相信我，您不需要）。然后是链接——你打算用这些做什么？理想情况下，您应该跟踪它们并确定它们是否进入同一文档的特定子部分（这将成为带有 goto-view 操作的链接），或者它们是否进入网络（这将成为一个链接带有打开的 URI 操作），或者如果您要转换多个文档，是否应该在文档上有一个基本 URI 和相对 URI'
此外，还有导航和文档结构的概念。理论上，您应该能够抓取<H1>和其他标题标签，并为每个标签构建一个带有 goto view 操作的大纲树。
您应该注意的其他事项 - PDF 模型对大型文档组件（如图像、字体、colo 空间等）采用基于资源的方法，以便可以共享它们。考虑到这一点来构建渲染器通常会产生更好的 PDF 并使用更少的内存。如果您的 PDF 生成器允许这样做，您真的应该能够为特定图像创建资源并尽早将其写入文档（或临时文件），然后在将其放置在页面上时通过资源句柄引用它。对同一图像的其他引用将使用句柄并且不再占用文件中的空间。字体也是如此——如果您使用特定的字体，提前了解它们并拥有一个引擎会在使用它们时自动对它们进行子集化会有所帮助。
If you have the HTML renderer and the PDF back end, then this task should take you two weeks, maybe three, again assuming that your HTML front end and PDF back end are half reasonable.
于 2012-11-21T14:53:34.310 回答