我有一个HTML（而不是XHTML）文档，可以在Firefox3和IE7中显示良好。它使用相当基本的CSS来设置样式，并在HTML中呈现良好的效果。
我现在正在寻找一种将其转换为PDF的方法。我尝试过：
DOMPDF：它在表格方面存在巨大问题。我分解了我的大型嵌套表，这有助于（之前它只消耗了128M的内存，然后就死了——这是我在php.ini中的内存限制），但它把表弄得一团糟，而且似乎没有图像。这些表格只是一些基本的东西，带有一些边框样式，可以在各个点添加一些线条；HTML2PDF和HTML2PS：实际上我在这方面运气更好。它呈现了一些图像（所有图像都是Google Chart URL），表格格式要好得多，但它似乎有一些复杂性问题，我还没有弄清楚，并且一直因未知的node_type（）错误而死亡。不知道从这里去哪里；和Htmldoc：这在基本的HTML上似乎很好，但几乎不支持CSS，所以你必须用HTML做所有的事情（我没有意识到在Htmldoc领域还是2001年…），所以这对我来说是无用的。
我尝试了一个名为Html2Pdf Pilot的Windows应用程序，它确实做得很好，但我需要至少在Linux上运行，最好通过Web服务器上的PHP按需运行的应用程序。
我缺少什么，或者如何解决这个问题？
经过一些调查和一般的头发拉扯，解决方案似乎是HTML2PDF。DOMDF在表格、边框甚至是中等复杂的布局方面做得很糟糕，htmldoc看起来相当健壮，但几乎完全不了解CSS，我不想只为该程序而回到没有CSS的HTML布局。
HTML2PDF看起来是最有前途的，但我一直有一个关于node_type的空引用参数的奇怪错误。我终于找到了解决办法。基本上，PHP5.1.x在任何大小的字符串上都可以使用正则表达式替换（preg_replace_*）。PHP 5.2.1引入了一个名为pcre.backtrack_limit的PHP.ini配置指令。此配置参数的作用是限制匹配所需的字符串长度。我不知道为什么要这样做。默认值选择为100000。为什么值这么低？同样，不知道。
针对PHP 5.2.1提出了一个bug，该bug在近两年后仍然开放。
最可怕的是，当超过限制时，替换就会默默地失败。至少，如果一个错误被引发并记录下来，你会知道发生了什么，为什么，以及要修改什么来修复它。
所以我有一个70k的HTML文件要转换成PDF。它需要以下php.ini设置：
pcre.backtrack_limit=2000000；#可能比我需要的更多，但没关系内存限制=1024M；#是的，1千兆字节；和最大执行时间=600；#是的，10分钟。
现在精明的读者可能已经注意到我的HTML文件小于100k。我可以猜测为什么会遇到这个问题的唯一原因是，作为过程的一部分，html2pdf将转换为xhtml。也许这让我着迷了（尽管近50%的膨胀似乎很奇怪）。不管是什么情况，上述方法都奏效了。
现在，html2pdf是一个资源占用者。我的70k文件需要大约5分钟和至少500-600M的RAM才能创建一个35页的PDF文件。不幸的是，对于实时下载来说（到目前为止）还不够快，内存使用率使内存使用率达到1000比1（70k文件需要600M RAM）的量级，这是非常荒谬的。
不幸的是，这是我想出的最好的办法。
经过一些调查和一般的头发拉扯，解决方案似乎是HTML2PDF。DOMDF在表格、边框甚至是中等复杂的布局方面做得很糟糕，htmldoc看起来相当健壮，但几乎完全不了解CSS，我不想只为该程序而回到没有CSS的HTML布局。
HTML2PDF看起来是最有前途的，但我一直有一个关于node_type的空引用参数的奇怪错误。我终于找到了解决办法。基本上，PHP5.1.x在任何大小的字符串上都可以使用正则表达式替换（preg_replace_*）。PHP 5.2.1引入了一个名为pcre.backtrack_limit的PHP.ini配置指令。此配置参数的作用是限制匹配所需的字符串长度。我不知道为什么要这样做。默认值选择为100000。为什么值这么低？同样，不知道。
针对PHP 5.2.1提出了一个bug，该bug在近两年后仍然开放。
最可怕的是，当超过限制时，替换就会默默地失败。至少，如果一个错误被引发并记录下来，你会知道发生了什么，为什么，以及要修改什么来修复它。
所以我有一个70k的HTML文件要转换成PDF。它需要以下php.ini设置：
pcre.backtrack_limit=2000000；#可能比我需要的更多，但没关系内存限制=1024M；#是的，1千兆字节；和最大执行时间=600；#是的，10分钟。
现在精明的读者可能已经注意到我的HTML文件小于100k。我可以猜测为什么会遇到这个问题的唯一原因是，作为过程的一部分，html2pdf将转换为xhtml。也许这让我着迷了（尽管近50%的膨胀似乎很奇怪）。不管是什么情况，上述方法都奏效了。
现在，html2pdf是一个资源占用者。我的70k文件需要大约5分钟和至少500-600M的RAM才能创建一个35页的PDF文件。不幸的是，对于实时下载来说（到目前为止）还不够快，内存使用率使内存使用率达到1000比1（70k文件需要600M RAM）的量级，这是非常荒谬的。
不幸的是，这是我想出的最好的办法。
就成本而言，在许多情况下，使用web服务（API）可能是更明智的方法。此外，通过外包这一过程，您可以减轻自己的基础设施/后端负担，并且-如果您使用的是信誉良好的服务-确保与调整web标准、正常运行时间、短处理时间和快速内容交付的兼容性。
我已经对目前市场上的大多数web服务进行了一些研究，请在下面找到我认为值得在这个线程中提及的API，按照价格/价值比的顺序排列。所有这些都提供预先编写的PHP类和包。
pdflayer.com-成本：$-质量：☆☆☆☆docraptor.com-成本：$$-质量：☆☆☆☆☆pdfcrowd.com-成本：$$-质量：☆☆☆
质量：
DocRaptor以高质量的引擎PrinceML为主干，显然提供了最佳的PDF质量，返回了经过高度抛光和良好转换的PDF文档。然而，pdflayer API服务在这里非常接近。Pdfcrowd不一定以质量得分，而是以处理速度得分。
成本：
pdflayer.com-如上所述，这里最具成本效益的选择是pdflaye.com，它提供100个月PDF的完全免费订阅计划，以及9.99美元至119.99美元不等的溢价订阅。每月10000份PDF文档的价格为39.99美元。
docraptor.com-提供7天免费试用期。高级订阅计划从15美元到2250美元不等。每月10000份PDF文档的价格约为300.00美元。
pdfcrowd.com-免费提供100个PDF。高级订阅计划从9美元到89美元不等。每月10000份PDF文档的价格约为49.00美元。
我已经使用了这三种方法，这段文字应该可以帮助任何人做出决定，而无需支付所有费用。本文并非为任何一种产品背书，我与任何产品都没有关联。
