HTML到PDF的转换真的需要使用PHP在服务器端进行吗？

我刚刚遇到了jsPDF，一个使用HTML5/JavaScript的客户端解决方案。MIT授权代码也在GitHub上。

HTML到PDF的转换真的需要使用PHP在服务器端进行吗？

我刚刚遇到了jsPDF，一个使用HTML5/JavaScript的客户端解决方案。MIT授权代码也在GitHub上。

我建议按照TCPDF或DOMPDF的顺序。

使用MPDF！==

a） 在文件夹中提取

b） 在您的文件夹中创建file.php并插入以下代码：

<?php
include('../mpdf.php');
$mpdf=new mPDF();
$mpdf->WriteHTML('<p style="color:red;">Hallo World<br/>Fisrt sentencee</p>');
$mpdf->Output();   exit;
 ?>

c） 从浏览器中打开file.php

2） 使用pdfToHtml！

将pdftohtml.exe解压缩到根文件夹：在该文件夹的anyfile.php文件中，输入以下代码（假设也有一个源example.pdf）：输入FinalFolder，将有转换后的文件（与源PDF一样多的页面）

经过一些调查和一般的头发拉扯，解决方案似乎是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）的量级，这是非常荒谬的。

不幸的是，这是我想出的最好的办法。

如果您可以访问命令行，则可以使用PhantomJS从URL（远程或本地）创建PDF。

它工作得很好，是一个免费的解决方案。

看看这个为这个问题制作的示例脚本。