有很多API或SDK可供开发人员编写PDF转换器。 PDFLib，TCPDF，DOMPDF等
还有现成的PDF转换器，但它们没有我想要的所有选项。所以我想也许最好只编写我自己的转换器。
如果您自己坐下来使用HTML-to-PDF转换器，约需要多长时间？在到达任何地方之前，是否需要您编写完整的HTML解析器？
我的应用程序所需的主要功能是拥有自定义文档大小，以及包含文本和图像的绝对定位的div。没有iframe。
答案 0 :(得分：3)
以下是您应该如何考虑这项任务的方法 - 您不是将HTML转换为PDF，而是编写一个将HTML呈现为PDF的渲染器。
因此，如果您没有HTML渲染器的shell，那么这是您的第一步。它应该采用HTML并且给定“窗口大小”将调用您实现的一组方法来渲染基元（绘制线条，放置图像，放置文本，放置链接等）。毫无疑问，您会遇到HTML页面没有固定高度和PDF页面的问题。
接下来，您将需要一个不错的PDF后端。通过体面，我的意思是它不会在大量图像上爆炸，以理智的方式处理资源，等等。它也应该有合理的Unicode支持，这样如果你发送一个Unicode字符串，它将自动执行PDF工作以正确呈现它，这样你就不必手动完成这项工作（相信我，你没有）。然后有链接 - 你打算用那些做什么？理想情况下，您应该跟踪它们并确定它们是否转到同一文档的特定子部分（这将成为带有goto-view操作的链接），或者它们是否会进入Web（这将成为一个链接）使用开放的URI操作），或者如果您要转换多个文档，是否应该在文档和相对URI上有一个基本URI，或者它是否应该是文件交叉链接等。
此外，还有导航和文档结构的概念。从理论上讲，您应该能够获取<H1>和其他标题标记，并为每个标记标记构建一个带有goto视图操作的大纲树。
您应该注意的其他事项 - PDF模型采用基于资源的方法处理大型文档组件，如图像，字体，colos空间等，以便可以共享它们。考虑到这一点构建渲染器通常会产生更好的PDF并使用更少的内存。如果您的PDF生成器允许这样做，您应该能够为特定图像创建资源并将其早期写入文档（或临时文件），然后在将其放在页面上时通过资源句柄引用它。对同一图像的其他引用将使用句柄并且不占用文件中的更多空间。字体的方式是相同的 - 如果你使用特定的字体，它有助于预先了解它们，并且有一个引擎可以在它们被使用时自动对它们进行子集化。
如果你有HTML渲染器和PDF后端，那么这个任务应该花费你两周，也许三个，再次假设你的HTML前端和PDF后端是合理的。