pdf转图片开源工具

来源：互联网发布：个性化推荐算法 php 编辑：程序博客网时间：2024/06/05 19:55

最近项目中有个需求需要把PDF转成一张图。经过调查，有三款比较流行的Java开源软件有这个功能。但在使用过程中，它们的区别还是很大的。下面对这三款软件Pdf-renderer, PDFBox 和JPedal做一个简单的介绍。

    首先，这三个工具的定位是不同的。
    PDF-Renderer是早日Sun公布的一个开源项目，它主要目的是方便用户展示PDF文档。通过解析PDF文档，使用户能够在自己的应用中查看，预览，绘制PNG和合并到3D的场景中。
    PDFBox是Java实现的PDF文档协作类库，提供PDF文档的创建、处理以及文档内容提取功能。它还包含比较多的命令方式方便用户处理PDF。它的强大功能是处理解析PDF文档。而且业界使用是比较广泛和稳定的。
    JPedal是IDRsolutions公司的一个产品。而这个产品在PDF解析和PDF展示中都有着比较专业的表现。JPedal只开源其中的一小部分功能。其中PDF转图片的功能是在LGPL下面的。

    从上面的定位来看， PDF-Renderer应该是比较吻合我们的要求的。下面分别从图片质量，效率方面来简单的做个比较。
    下面是三款工具从PDF中转成的图片：

                                            PDF-renderer

PDFbox

Jpedal

从图片质量上来看，除了PDBbox有条线没有成功画出来后，基本上差不多（当然，在像素上PDFbox是最高的）。但他们之间的转化效率还是差别很大的。在转化效率上，经过测试表现不如意的是PDFBox，其次是Jpedal. 最好的是PDF_renderer. 在我的测试中PDF-renderer的转化效率大约是Jpedal的两三倍。而Jpedal的转化效率大约是PDFbox的3倍多。

但是，经过一定量文档的测试，发现很多PDF文档是不能被PDF-renderer处理的。一个主要原因是PDF-renderer的字体不全。而PDFbox有自己的字体包，在不能转化时，会转化到默认字体处理。目前测试中，还没碰到PDFbox和Jpedal不能处理的文档。由于PDFbox有时候，不能正确的扑捉的表格线，所以我们这次的项目中选择使用Jpedal. 除了Jpedal是家商业公司的产品外，似乎没有不用的理由。

      在项目使用过程中，由于我们使用多线程批量转化。出现过内存溢出的问题。特别是使用PDFbox时候，它需要的内存会更多。这里顺便简单谈下自己是怎样追踪解决内存溢出的问题。也许大家有更好的办法，热烈欢迎大家给我意见。

      首先，可能大家自然的会想到利用jvisualvm，装个插件就可以动态的观察内存使用情况。甚至随时可以把线程堆栈，CPU和内存快照弄出来。但如果是在大的应用系统中，内存本来就很吃紧，开个 jvisualvm基本上就死在那里不动了。这里想到的就是利用gc log 和内存溢出后的堆栈信息来处理。
      在JVM启动中，加入下面的配置参数

Java代码  
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:D:/java/gc/gc.log -XX:+HeapDumpOnOutOfMemoryError  

打开gc的详细log并写入到一个单独文件中。其中HeapDumpOnOutOfMemoryError的配置，会在内存溢出时候写一个java_pidXXXX.hprof的文件到jvm启动的第地方。利用Eclipse Memory Analysis插件，打开这个文件后，我们可以获得到内存溢出时候的内存堆栈信息。其中有个Leak Suspects 功能，把认为最有可能导致内存溢出的objece分析出来。如下图：

从图中可以发现，有两个比较可疑的地方。第二个正是我们转图片用的。然后我们就可以去改进我们的代码。

上面我们还提到过gc日志文件。通过分析gc日志，我们大概可以了解到JVM堆内存使用情况。这里介绍一个taobao人开发的查看gc日志的工具。很小很好用。http://code.google.com/p/gclogviewer/ 现在的版本只能画图，下个版本除了画图的性能提高外，还会增加调优的建议。下面是我改动代码前后的两个gc图。

从这个图中，可以看出内存一直在涨，直至崩溃。

这是改动代码后的一个图：

这个图，内存趋于稳定了。但转化过程中，一直处于Full GC. 应用暂停很严重。幸好这是在后台的一个数据订正程序。性能优化还有很多可以做。