首页->大浪淘沙 DjVu转PDF作者：马健
一、引言 在扫描电子文档领域，PDF与DjVu各有特色，也都各有一些坚定的支持者，所以网上经常能看到求助实现两种格式互相转换的帖子——都希望能转成自己或别人喜欢的格式。网上提供的解决方案也多种多样，从最简单的虚拟打印（PDF与DjVu均有虚拟打印机），到使用专门的工具 （单步）或工具集合（多步）转换都有。 出于兴趣，我最近也在这方面进行了一些技术探索，不过重点不在结果本身（我个人一直不主张在不同格式之间转来转去穷折腾），而在过程：希望能从技术角度比较PDF与DjVu内部数据结构，尽量实现无损转换，同时保持文件长度变化不大。 本文就是上述过程的一个记录。 按我个人的理解，DjVu的高压缩比主要来自以下几个方面：
与ISO 32000-1相对照，其实以上特性在PDF中也有：
所以，在理论上，大多数DjVu可以在转换成PDF时，做到在文件长度变化不大（变化还是有，毕竟文件结构方面存在差异）的情况下，数据无损（JB2->JBig2）或视觉无损（IW44->JPEG 2000）。 注意我说的是“大多数DjVu”，因为如果细看Lizardtech公司2005年版《DjVu Reference v3》，就可以看到其中定义了一种称为“彩色JB2（Colorized JB2）”的东东，我在PDF里没有找到直接对应。不过幸好想制作出这种格式的DjVu也不是一件容易的事情，至少国内主要的DjVu文件来源，包括中美百万、CX等，都没有这种格式的DjVu，所以我上面说是“大多数DjVu”。 另外JB2与JBig2的相似性也不是偶然的，在AT&T的Patrick Haffner、Leon Bottou、Yann Lecun与Lizardtech公司的Luc Vincent合著的论文《A General Segmentation Scheme For DjVu Document Compression》第2章中，对JB2算法的来历进行了介绍： The mask image is encoded with a new bi-level image compression algorithm called JBZ or DjVuBitonal. It is a variation on AT&T's proposal to the emerging JBIG2 standard. The basic idea of JB2 is locate individual shapes on the page (such as characters), and use a shape clustering algorithm to find similarities between shapes. Shapes that are representative of each cluster (or in a cluster by themselves) are coded as individual bitmaps with a method similar to JBIG1. 看来不仅名字相似，JB2与JBig2追到根子上还有血缘关系，不过似乎JBig2后来又发展出了一些新花样，而JB2就此颓废了——所托非人啊！ 理论说上一大堆，如果没有一个实际实现，总还是觉得有点虚。所以我就以FreePic2Pdf的PDF生成引擎为基础，加入对DjVu的支持，最终在DjVuToy中实现了DjVu转PDF功能：一次可以转换一本书，包括多级书签，但不支持隐藏文本和注释。 下面分别介绍一下其中几个关键技术的实现原理和方法，及对最终结果的验证。 这个部分初看起来似乎没啥悬念：把JB2中的字典、页面描述解码出来，按照JBig2的要求重新编码、封装即可，中间不需要全图转换成位图后重新分割、聚类。 但是实际做过以后才会知道，这中间还是有讲究的：如果不对字典进行处理，直接就编码、封装，最终的结果大概会比最初的JB2数据流长约20%。其中的原因我也是看了Adam Langley的jbig2enc才明白：如果字典中的某些符号在页面描述中多次出现，可以把这些符号单独编成一个字典，那些只出现一次的符号编成另外一个字典，这样可以减小页面描述中的索引位数，最终减小整个数据流长度。这种技术没看到有谁专门命名，姑且称之为“字典二次编码”技术。这种技术对多页共用字典 固然有影响，多单页独享字典也有影响。 除了上述字典二次编码技术外，JBig2的算术编码效率也对最终数据流长度有影响，不过这部分太复杂了，不是一般人能搞定的。 对最终编码结果的验证则很简单：
我本人的数学基础不太好，对小波分析更是望而生畏，所以没有研究是否可能像JB2->JBig2那样，在不解码成位图的情况下实现直接转换，而是采用了一个偷懒的笨办法：先把IW44解码成位图，根据解码前后的数据流长度可以算出压缩比，然后按照这个压缩比，再把位图压缩成JPEG 2000。这里面的关键就是：JPEG 2000压缩允许指定压缩比，保证压缩出来的数据流长度在指定的范围内。 对最终编码结果的验证也很简单：
如果有谁对小波比较精通，不妨对IW44和JPEG 2000进行一下深入研究，我总觉得这二者是可以直接转换的——研究有成果了别忘记通知我一声。 对于DjVu的多层混合显示，在PDF中有不止一种方法可以实现，甚至连DjVu中没有的半透明效果都可以实现。不过最终我选择了用SMask实现，原因很简单：用这种方式在Acrobat中显示时可以指定背景色 ，即成为常说的“透明背景PDF”。 这个的验证没啥好说的，在浏览器里打开看一下就知道了。这个例子是一个三层结构的DjVu文件及转换后的PDF文件，有兴趣的可以比较一下显示效果 。内部数据的比较结果如下：
各位如果有兴趣，不妨把这个例子DjVu另存为单张静态图像，可以看到文件长度急剧膨胀，对照一下将有助于理解我前面说的DjVu高压缩比的原因。 “彩色文本”是DjVu的一个独门绝技。如果页面中含有彩色文字，在DjVu中可以有两种实现方法（参见Lizardtech公司2005年出版发行的《Lizardtech DjVu Reference DjVu V3》第7.1.3.1节“Foreground Encoding”）：
两种方法相比较，后者的编码效率要更高一些，显示时的文字颜色也比较纯正，缺点是每个符号的颜色必须是单一纯色，不能出现变化（如渐变色文字）。而前者的适应范围无疑要更广泛一些，压缩比问题也 通常通过缩图解决，如长宽缩至1/12，则面积仅为原先的1/144，还没开始编码就轻松超过1:100的压缩比。大概正因为如此，所以常见的DjVu都采用了常规三层结构，采用彩色文字的很少见。 以我对PDF的了解，采用彩色文字的DjVu如果想转换成PDF，最无损的办法大概是：把Sjbz数据段拆成“字典”和“页面描述”两个部分，字典中的符号封装成点阵字体嵌入PDF，页面描述中的说明转换成PDF的字符输出指令，FGbz中的颜色描述则转换成PDF的前景色设置指令。显示的时候，按照指定的颜色显示字符，字符点阵来自内嵌字体。 这种方法好是好，但是其中过程的复杂性我只是想一想就失去了尝试的勇气。所以最终还是采用了偷懒的办法：把彩色文字转换成常规三层结构。这种方法实现简单，但是会导致转换出来的PDF文件长度增加许多。好在我自己平时不转，大就大吧。 综上所述，大多数DjVu在转换成PDF时，可以在文件长度变化不大的情况下，做到数据无损（JB2->JBig2）或视觉无损（IW44->JPEG 2000），前提是转换的方法和工具得当。 从这一点上说，“DjVu格式的压缩比高于PDF格式”的观点其实是不成立的——在“格式”上PDF也可以实现DjVu的高压缩比，因此二者的差异不在于“格式”，而在于把静态图像转换成最终“格式”的工具和方法。 目前常见的PDF制作工具，包括Acrobat，在将静态图像转换成PDF时，多半采用“嵌入”的方式，即将整个静态图像数据流甚至文件嵌入PDF文件中，不进行进一步的处理 （如按MRC模型分层）。这种方法的好处是技术简单、实现方便、图像可以完全无损，缺点是经常有人抱怨这样做出来的PDF文件比DjVu大得多。 而从前面的描述来看，DjVu的高压缩比与它的“分层结构、按需编码”有直接关系，而这是可以复制到PDF中来的。因此我认为如果想提高扫描版PDF的压缩率，可以在PDF制作软件上进行改进：引入商业DjVu制作软件的内核或引擎，对需要转换成PDF的扫描图像进行分层，然后按照分层结果选择最有效的图像压缩算法。即把上面说的“图像->DjVu->PDF”过程简化成“图像->PDF”，中间这一步在PDF制作软件内部悄悄完成了。 当然，如果不嫌麻烦，或者有OCR的技术积累，也可以自己去做分层的开发，但最终结果是一样的。其实在我第一次看到用luratech公司的产品制作出来的高压缩比PDF时，我就怀疑他们是这么干的。这也是促使我去写这篇文章的原因之一。 在讨论完DjVu转PDF后，一个很自然的问题就是：这样转换出来的PDF，能不能再转回DjVu？ 我对这个问题的回答是：看你想怎么转。最简单的办法当然是直接打印到DjVu虚拟打印机上，或者找一个现成的PDF2DjVu软件，喜欢折腾的也可以先把PDF转图片，然后图片转DjVu。 不过既然前面说了半天数据格式转换，那咱们的思维还是别太发散，还是按照同样的思路：能不能从PDF文件数据流里抽取图像数据流，及层次描述，然后尽量无损地转换回DjVu？我的回答是：不一定。理由如下：
因此，我至今也只实现了把PDF中的JBig2导出为DjVu，但不敢去试PDF->DjVu，而且建议各位也别闲来无事转着玩儿，不然哪天突然后悔了可没地儿买药去。 反向转换的研究虽然进行得不彻底，不过也产生了其他的副产品：在研究过程中，我感觉未来采用JPEG 2000压缩的PDF会增加，因此在UnicornViewer中专门加强了对这方面的支持，并且我名下所有与PDG相关的软件，均开始支持“名为PDG实为JPEG 2000的文件”：如果PDF中的图片实在转不回DjVu，干脆导出成图片看算了。
按照我前面说的方法和工具转换出来的PDF采用了JBig2、JPEG
2000压缩，前者要求Acrobat 5以上版本，后者要求Acrobat 6以上版本的浏览器才能正常显示。好在现在主流的Acrobat版本最低也是7。其他常见的PDF浏览器中，PDF-XChange支持这两种格式没有问题，Foxit需要专门的插件，CajViewer则不支持。我自己的UnicornViewer没有问题，在JPEG
2000方面还进行过专门强化，比Acrobat8的兼容性更好，不过解码速度是个大问题。 |