介绍几款PDF转图片的开源工具

最近项目中有个需求需要把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中转成的图片：


[size=large] [b]PDF-renderer[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551828/ee546739-d2ee-3737-b90b-bda5a26c06e8.png[/img]


[size=large][b] PDFbox[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551830/ee4d67f3-15cf-39de-80f4-5112cd01fcd8.png[/img]


[size=large][b] Jpedal[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551832/b25c7c01-8e56-3e19-93c9-816ce5305f30.png[/img]

从图片质量上来看， 除了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启动中，加入下面的配置参数

-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分析出来。如下图：
[img]http://dl.iteye.com/upload/attachment/551857/2ba9e916-0d9c-373d-894b-f92a14716416.png[/img]

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

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

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


这是改动代码后的一个图：
[img]http://dl.iteye.com/upload/attachment/551868/1b291528-55e9-307e-adbc-221f688ef54c.png[/img]
这个图， 内存趋于稳定了。 但转化过程中， 一直处于Full GC. 应用暂停很严重。 幸好这是在后台的一个数据订正程序。性能优化还有很多可以做。