DjVu转PDF

时间 2019-11-20

标签 djvu pdf 繁體版

原文原文链接

做者：马健
邮箱：stronghorse_mj@hotmail.com
发布：2009.09.22
更新：
2012.06.11
针对PdfToy的新进展，更新了相关内容。php

1 引言
 2 理论
 3 实现
    3.1 MRC模型的转换
        3.1.1 单层DjVu
        3.1.2 3层DjVu
        3.1.3 2层DjVu（彩色文本）
    3.2 图像的转换
        3.2.1 JB2转JBig2
        3.2.2 IW44转JPEG 2000
        3.2.3 JPEG与CCITT G4的转换
    3.3 隐藏文本的转换
    3.4 目录的转换
    3.5 其余部分的转换
 4 结论
 5 引伸
    5.1 用DjVu技术制做PDF
    5.2 反向转换
    5.3 PDF浏览器限制html

1 引言

在扫描电子文档领域，PDF与DjVu各有特点，也都各有一批坚决的支持者，因此网上常常能看到求助实现两种格式互相转换的帖子——都但愿能转成本身或别人喜欢的格式。网上提供的解决方案也多种多样，从最简单的虚拟打印（PDF与DjVu均有虚拟打印机），到使用专门的工具（单步）或工具集合（多步）转换都有。算法

出于兴趣，我最近也在这方面进行了一些技术探索，不太重点不在结果自己（我我的一直不主张在不一样格式之间转来转去穷折腾），而在于转换的过程：但愿能从技术角度比较PDF与DjVu的模型与内部数据压缩算法，尽可能实现无损转换，同时保持文件长度变化不大。浏览器

本文就是上述过程的一个记录。less

2 理论

按我我的的理解，DjVu的高压缩比主要来自如下几个方面：ide

基于MRC（Mixed Raster Content，参见ISO/IEC 16485）模型的分层结构：将扫描图像分解成前景、背景、蒙板层，而后针对不一样层的特色，采用最适合的图像压缩算法。在表达文字、图像混合的点阵图像时，这种方法无疑比传统不分层的、眉毛胡子一把抓的静态图像压缩格式（如JPEG、JPEG 2000、PNG、TIFF、GIF等）更优秀。另外按照ISO/IEC 16485的建议，若是对图像先分割成子区域（strip）再进行分层，或采用N层结构，可能得到更高的压缩性能。不过DjVu大概认为追求这样的性能提升不太值得，因此一直坚持采用MRC的基本三层模型。
在分层的基础上，DjVu从阅读心理出发，认为阅读者对扫描页面文字部分的关注度，要高于对插图、底纹的关注度。所以对于文字部分，不对像素尺寸进行缩减，保持尽量高的清晰度和分辨率；而对于插图、底纹部分，通常先进行缩图，而后再有损压缩——一般长、宽缩至原来的1/3～1/12，显示的时候再放大回来。简单算一下就能够知道，就算长、宽只缩至1/3，图像面积也只有原来的1/9大，即还没怎么着呢就轻松达到1:9的压缩比，天然可以大大减少最终的文件长度，付出的代价是：不少DjVu文件的插图看起来模模糊糊的，这其中的缘由除了有损压缩外，图像缩放更主要。DjVu文件各层的像素尺寸，能够从DjVuToy导出的DjVu文件信息中看到，有兴趣的不妨看一看。那些常常问“为何我看到的DjVu这么模糊？”或“为何国外的DjVu比国内的DjVu更清晰？”的人，更应该好好看看。
在编码方面，DjVu的文字层采用JB2压缩算法。这种算法的核心思想是：把整页文字切分红一个个符号（shape），相同的符号再也不重复编码，这样整页文字能够用一个无重复的符号集合（称为“字典”，dictionary）、一个页面描述集合来表示。单条页面描述能够用三元组（idx，x，y）表示，idx表明符号在字典中的序号，（x，y）是该符号的显示位置，说白了每条页面描述的意思就是：在（x，y）处显示编号为idx的符号。采用这种方式，不只页面中的空白部分再也不须要编码，并且对于印刷字体（尤为是字母文字），每一页中符号的重复程度是很可观的，这些重复的符号编码也均可以省略了，因此压缩比要比常规静态图像要大。不过这种算法的问题是：如何判断两个符号是相同的？毕竟图像是扫描出来的，二值化后字符边缘充满了毛刺，要说两个字一个像素不差不太可能，总要有一个容忍程度，差别超过此容忍程度即认为两个符号不一样，不然认为相同。在常规DjVu制做软件中，通常提供给用户三种选择：无损（lossless）、清洁（clean）、有损（lossy），容忍程度从小到大，而最终文件长度则从大到小。DjVu一贯标榜的就是高压缩比，因此常规制做软件的缺省选择都是有损，这样就可能由于把类似字误判为相同字而出现错别字：
http://djvu.org/forum/phpbb/viewtopic.php?t=659
http://readfree.net/bbs/read.php?tid=277235
这个问题是JB2有损压缩的原罪，理论上很难彻底避免，实际上各DjVu生成引擎都会在内部进行一些判别以求弥补，但效果如何谁也说不清。因此在有足够的证据（我很怀疑有谁能提出这样的证据）证实某个DjVu引擎不会对中文类似字进行误判以前，我绝对不可能把我本身须要保留的文件压缩成有损JB2。固然，给别人看的就另当别论了，错不错的关我P事？
另外这种判别与图像的扫描DPI密切相关，DPI值低于300时误判的可能性要比300 DPI及其以上的误判可能性更大。按照国外扫描界的要求（参见大名鼎鼎的《The Scan and Share tutorial version 1.07》），扫描时应该用300 DPI灰度扫描，而后用软件放大至600 DPI，再处理成DjVu。这就是为何有些人总以为国外的DjVu比国内的更清晰的缘由：你们的DPI不同！
DjVu的插图、底纹部分一般采用IW44压缩算法，这种算法基于小波（Wavelet）分析，原理基础和JPEG 2000差很少，通常采用较高压缩比，代价是图像质量用肉眼就能看出是有损的。

与ISO 32000-1相对照，其实以上特性在PDF中也有：工具

PDF的transparent imaging model支持多层结构，包括透明、半透明，比DjVu的模型结构复杂多了。
从PDF 1.4（对应Acrobat5）开始支持JBig2压缩，这种压缩算法在核心思想上（参见ISO/IEC 32000-1:2008第7.4.7节、ISO/IEC 14492:2001）与DjVu的JB2压缩如出一辙。不过JBig2考虑的范围更普遍一些，除文字、线型图外，还考虑到半调（halftone）图像等，所以定义远比JB2复杂。换句话说，JB2数据流能够彻底转换成JBig2数据流，可是反向就不必定了——JBig2中的某些东西在JB2中没有对应。
从PDF 1.5（对应Acrobat6）开始支持JPEG 2000压缩，这种压缩算法的理论基础与DjVu的IW44压缩同样，都是基于小波分析。从实际图像测试结果看，对于同一张连续色调图像，这两种算法在一样的压缩比下，最终的视觉效果差异不明显。换句话说，对于同一张图像，这两种算法压缩出来的文件长度能够差很少，视觉效果也差很少。

因此，在理论上，大多数DjVu能够在转换成PDF时，作到在文件长度变化不大（变化仍是有，毕竟文件结构方面存在差别）的状况下，数据无损（JB2->JBig2）或视觉无损（IW44->JPEG 2000）。性能

注意我说的是“大多数DjVu”，由于例外老是存在的。学习

3 实现

理论说上一大堆，若是没有一个实际实现，总仍是以为有点虚。因此我就以FreePic2Pdf的PDF生成引擎为基础，加入对DjVu的支持，最终在DjVuToy中实现了DjVu转PDF功能：一次能够转换一本书，除图像外还包括多级书签、隐藏文本，但不包括注释、缩略图等。测试

下面分别介绍一下其中几个关键技术的实现原理和方法，及对最终结果的验证。

3.1 MRC模型的转换

前面说过，DjVu的基本图像模型是ISO/IEC 16485 MRC三层模型，但并不是全部DjVu都凑足了三层，有些只有单层或2层。

单层DjVu：又称为Photo DjVu（彩色、灰度）或Bi-Level DjVu（黑白），一页只有一层图像，彩色、灰度图像能够采用IW44或JPEG压缩，黑白图像采用JB2或CCITT G4压缩。
2层DjVu：又称为彩色文本（Color Text）DjVu，即只有前景层（JB2压缩或CCITT G4压缩）和背景层（IW44或JPEG压缩），但前景层容许带颜色，此时的JB2又称为Colorized JB2。这是对原JBig2标准的扩展，为DjVu所独有。
3层DjVu，即包含蒙板层、前景层、背景层这3层的DjVu。蒙板层为黑白图像，能够采用JB2或CCITT G4压缩；前景层、背景层为灰度或彩色图像，能够采用IW44或JPEG压缩。

下面针对这三种状况，讨论DjVu的MRC到PDF图像模型的转换。

3.1.1 单层DjVu

单层DjVu其实就是单一的图像，与PDF中的图像能够直接创建对应关系，所以单层DjVu转PDF不涉及太多模型层面的东西，转换的时候将整幅图像插入PDF页面中便可。

3.1.2 3层DjVu

3层DjVu也不复杂，PDF的图像模型中一样容许使用蒙板，甚至容许指定蒙板的透明度（权重），所以3层DjVu转PDF，在模型上也没有太多的问题，只在于怎么选择合适的蒙板表示而已。

最终我选择了用SMask实现，缘由很简单：用这种方式产生的PDF在Acrobat中浏览时能够指定背景色，即成为常说的“透明背景PDF”。

这个例子是一个三层结构的DjVu文件及用DjVuToy转换后的PDF文件，有兴趣的能够比较一下显示效果。内部数据的比较结果以下：

DjVu：蒙板层像素尺寸2774×3543，数据流长度26896字节；前景层232×296（长、宽仅为蒙板层的1/12），数据流长度5138字节；背景层925×1181（长、宽仅为蒙板层的1/3），数据流长度34334字节。
PDF：各层像素尺寸与DjVu同样，数据流长度分别是：27424字节、5083字节、34386字节，差异不大。

各位若是有兴趣，不妨把这个例子DjVu另存为单张静态图像，能够看到文件长度急剧膨胀，对照一下将有助于理解我前面说的DjVu高压缩比的缘由。

DjVu转PDF的官方转换软件Caminova DocumentExpress Enterprise 7.5（简称deent75）在转换多层DjVu的时候，有一个噱头：转换出来的PDF带有图层控制，能够在用Acrobat浏览的时候，指定显示前景层或背景层。我我的以为图层控制会增长PDF文件的长度，并且支持图层控制的PDF浏览器和会用的人都不多，因此就没管它。

DjVuToy的噱头是：转换出来的PDF是背景透明的，不管是单层仍是多层，用户在浏览的时候均可以指定背景色。

3.1.3 2层DjVu（彩色文本）

“彩色文本”是DjVu的一个独门绝技。若是页面中含有彩色文字，在DjVu中能够有两种实现方法（参见Lizardtech公司2005年出版发行的《Lizardtech DjVu Reference DjVu V3》第7.1.3.1节“Foreground Encoding”）：

常规三层法：文字轮廓用JB2压缩，做为蒙板层（Sjbz）；颜色部分用IW44压缩，做为前景层（FG44）。上面这个例子就采用这样的技术。为了追求高压缩比，一般对前景层进行大比例缩图（如上面这个例子长宽缩至1/12），这样在还原显示的时候，文字颜色看起来可能会有点怪异，由于缩放后的前景层总会与原来的有点差别。
彩色文字法：文字轮廓用JB2压缩，成为蒙板层（Sjbz），而后对每一个符号的颜色进行编码，成为前景颜色层（FGbz）。

两种方法相比较，后者的编码效率要更高一些，显示时的文字颜色也比较纯正，缺点是每一个符号的颜色必须是单一纯色，不能出现变化（如渐变色文字）。而前者的适应范围无疑要更普遍一些，压缩比问题一般经过缩图解决，如长宽缩至1/12，则面积仅为原先的1/144，还没开始编码就轻松超过1:100的压缩比。

以我对PDF的了解，采用彩色文字的DjVu若是想转换成PDF，最无损的办法大概是：把Sjbz数据段拆成“字典”和“页面描述”两个部分，字典中的符号封装成点阵字体嵌入PDF，页面描述中的内容转换成PDF的字符输出指令，FGbz中的颜色描述则转换成PDF的前景色设置指令。显示的时候，按照指定的颜色显示字符，字符点阵来自内嵌字体。

这种方法好是好，可是其中的复杂性我只是想想就失去了尝试的勇气。因此最终仍是偷了个懒：把2层结构转换成常规3层结构。官方转换软件deent75用的也是这个方法，不过DjVuToy比deent75多了一个选择：能够选择转换时前景层的缩图比例。

在2层模型转成3层模型的时候，须要先把彩色前景层还原出来，而后再缩图成前景层，原蒙板层、背景层则不变，这样就将2层变成了3层。若是前景层不缩图，则转换出来的PDF在视觉效果上与原始DjVu是彻底同样的，可是文件长度会大增——多出来的前景层是灰度或彩色，不论采用JPEG仍是JPEG 2000压缩，若是画面尺寸降不下来，文件长度也就降不下来。

在deent75中，对前景层一概缩图至原像素长、宽的1/12，而DjVuToy的缺省值与deent75相同，但若是对质量很在乎而对文件长度不在乎，也能够手工设置缩图比例。

另外前景层图像的生成也颇有讲究，deent75的生成方法我模仿了好久也没有模仿出来，如今这个是通过大量实验获得的，在文件长度、图像质量方面不见得比deent75差。

3.2 图像的转换

3.2.1 JB2转JBig2

这个部分初看起来彷佛没啥悬念：把JB2中的字典、页面描述解码出来，按照JBig2的要求从新编码、封装便可，中间不须要全图解码成位图后再从新分割、聚类。

可是实际作过之后才会知道，这中间仍是有讲究的：若是不对字典进行处理，直接就编码、封装，最终的结果大概会比最初的JB2数据流长约20%。其中的缘由我也是看了Adam Langley的jbig2enc才明白：若是字典中的某些符号在页面描述中屡次出现，能够把这些符号单独编成一个字典，那些只出现一次的符号编成另一个字典，这样能够减少页面描述中的索引位数，最终减少整个数据流长度。这种技术没看到有谁专门命名，姑且称之为“字典二次编码”技术。这种技术对多页共用字典当然有影响，对单页独享字典也有影响。

除了上述字典二次编码技术外，JBig2的算术编码效率也对最终数据流长度有影响，不过这部分太复杂了，不是通常人能搞定的。

对最终编码结果的验证则很简单：

用DjVuToy能够导出DjVu文件结构，用PdfToy或免费开源的PdfView能够导出PDF文件结构，比较一下其中JB二、JBig2数据流的长度，便可知道编码效率的差别。从实际测试结果看，差别有一些，可是绝对没有网上常见的DjVu宣传资料上宣称的那么大。
用PdfToy或UnicornViewer 0.17以上版本可将PDF中的JBig2数据流转换成JB2并封装成DjVu文件，用DjVuToy可导出转换先后的DjVu文件的字典、页面描述，用FindDupFile可验证这两个文件的字典彻底相同，页面描述用Excel从新排序后也能够验证彻底相同，所以可认为JB2转JBig2及反向的JBig2转JB2过程均是彻底无损的。

这样的验证其实说明一件事：对于采用JB2压缩的单层DjVu，能够用DjVuToy无损转换成PDF，文件长度也差很少。

另外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就此颓废了——所托非人啊！

3.2.2 IW44转JPEG 2000

我本人的数学基础不太好，对小波分析更是望而生畏，因此没有研究是否可能像JB2转JBig2那样，在不解码成位图的状况下实现直接转换，而是采用了一个偷懒的笨办法：先把IW44解码成位图，根据解码先后的数据流长度能够算出压缩比，而后按照这个压缩比，再把位图压缩成JPEG 2000。这里面的关键就是：JPEG 2000压缩容许指定压缩比，保证压缩出来的数据流长度在指定的范围内。

对最终编码结果的验证也很简单：

用DjVuToy导出DjVu文件结构，用PdfToy或PdfView导出PDF文件结构，比较其中BG4四、FG44与JPXDecode数据流的长度，便可知道编码效率的差别。从实际测试结果看，差别能够忽略。
用PdfToy或UnicornViewer 0.17以上版本能够将PDF中的JPEG 2000图像无损导出，用图像比较软件能够从统计角度定量比较两者的差别，也能够直接用肉眼比较一下，在我看来都差很少，基本上能够认为是“视觉无损”，除非压缩率超过了必定限度。

若是有谁对小波比较精通，不妨对IW44和JPEG 2000进行一下深刻研究，我总以为这两者是能够直接转换的——研究有成果了别忘记通知我一声。

上面的JB二、IW44验证说明：对于3层DjVu，在用DjVuToy转换成PDF后，模板层确定是无损的，前景层、背景层视觉无损，文件长度差别不大。

对于2层DjVu，因为须要补充前景层，转换后文件长度增长会明显，前景层缩图形成的影响在某些状况下也是视觉可查的。

3.2.3 JPEG与CCITT G4的转换

按照《Lizardtech DjVu Reference DjVu V3》的规定，DjVu中的蒙板层除JB2压缩外，还能够采用CCITT G4压缩，其Chunk ID为Smmr；前景层、背景层除IW44外，还容许采用JPEG压缩，其Chunk ID分别为FGjp、BGjp。

因为这两种压缩算法的压缩效率与JB二、IW44相差太多，所以采用这两种压缩算法的DjVu文件在现实中根本没有，我本身测试用的文件也是用软件特地制做出来的。

PDF自己支持CCITT G四、JPEG压缩，所以采用这两种压缩的图像能够无损转换至PDF——CCITT G4可能还须要从新编码，JPEG图像整个嵌进去便可。

3.3 隐藏文本的转换

DjVu的设计初衷是针对扫描图像，但也提供隐藏文本功能，方便对文档内容进行检索、复制等。

DjVu中的隐藏文本经过OCR得到，带隐藏文本的DjVu习惯上称为“双层DjVu”，这实际上是从“双层PDF”沿用过来的——用扫描图像制做的PDF，也能够经过OCR生成隐藏文本。

在DjVu转PDF的过程当中，若是DjVu已经有隐藏文字，天然但愿可以直接转过去，不用再OCR。但其中涉及到DjVu与PDF的一个本质区别。

DjVu的设计目的从未变过，就是针对扫描图像，文字不过是辅助，所以DjVu中的文字是真正的“隐藏”文字，只有文字的编码（utf-8）、文字的位置，但不含任何字体信息，所以理论上是显示不出文字的，除非再额外指定字体。

PDF中的文字则与图像并列，显示出来是正常的，隐藏起来不过是特例。所以在PDF中，文字除了有编码、显示位置、显示比例外，还要有字体信息。因此在将DjVu中的隐藏文本转换成PDF时，麻烦就麻烦在字体上。

PDF中的字体能够是内嵌字体，也能够是外挂字体。具体哪一种更优，各人见解不一样。我本身是比较倾向于外挂字体。

PDF中对外挂字体有特殊规定，要求全部PDF浏览器均支持的14种标准字体中，就有9种是针对西欧拉丁语系（Latin 1），对CJK（中、日、韩）则规定了额外的标准字体，是否支持由各浏览器自行决定。Acrobat若是装了亚洲语言包，是能支持Adobe的CJK标准字体的。UnicornViewer是中国人开发的，对CJK的支持就更不用说了。

换句话说，若是采用外挂字体，其实只有Latin 1（西欧11国）和CJK（简、繁、日、韩）才能保证平台通用性，其它语言，如俄语，理论上说能够指定Windows的TrueType字体做为外挂字体，但其平台通用性没法保证。

在用deent75转换DjVu成PDF时，对于隐藏文字也只针对Latin 1和CJK的外挂字体转换。DjVuToy在隐藏文本转换方面彻底学自deent75，其位置与deent75的差别在小数点后第4位——DjVuToy我以为到小数点后第4位已经足够，deent75以为还应该保留更多的位数。

DjVuToy在模仿deent75的基础上，也作了一些改进：

强化了对中、日、韩竖排文字的支持。deent75彻底没有竖排的概念，这点很使人诧异，毕竟这家公司的总部就在亚洲。
容许将word合并成line。合并后单个word的位置可能出现变化，可是数据流长度大大减少，校对的时候也简单许多。
deent75转换出来的双层PDF是“图压字”，即隐藏文字在底层，图像在上层。这样的处理存在一些弊端，所以DjVuToy向Acrobat学习，采用了“字压图”的方法，即图像在底层，隐藏文字在上层。

总之，有些东西是用出来的。

3.4 目录的转换

目录在PDF中称为Outline，在DjVu中称为Bookmark、Contents，其实就是在浏览的时候，左侧显示出来的分级大纲。

DjVu中的目录其实比PDF简单得多，并且不能实现对跳转位置的精细控制：在PDF中，经过点击目录项既能够跳转到某一页，也能够跳转到页中的某个位置，而DjVu只能跳转到页，这点和PDG的目录差很少。

DjVuToy转换DjVu目录的时候就是直转，即将DjVu中的utf-8转换成PDF的Unicode，页码也照转。不过我也偷了点懒：DjVu中的目录容许跳转到某个文件或某个URL，DjVuToy对这些状况就无视了。

3.5 其余部分的转换

在DjVu中，还有注释、缩略图等内容，这些在PDF中都有对应，理论上说在转换成PDF也应该能转过去，不过我看官方的deent75也没管这些，因此我也都无视了，反正这些东东对我来讲也根本碰不到，不值得花时间。

4 结论

综上所述，大多数DjVu在转换成PDF时，能够在文件长度变化不大的状况下，作到数据无损（JB2转JBig2）或视觉无损（IW44转JPEG 2000），并能将隐藏文本、目录等一块儿转换过去，前提是转换的方法和工具得当。

从这一点上说，“DjVu格式的压缩比高于PDF格式”的观点实际上是不成立的——在“格式”上PDF也能够实现DjVu的高压缩比，所以两者的差别不在于“格式”，而在于把静态图像转换成最终“格式”的工具和方法。

5 引伸

5.1 用DjVu技术制做PDF

目前常见的PDF制做工具，包括Acrobat，在将静态图像转换成PDF时，多半采用“嵌入”的方式，即将整个静态图像数据流甚至文件嵌入PDF文件中，不进行进一步的处理（如按MRC模型分层）。这种方法的好处是技术简单、实现方便、图像能够彻底无损，缺点是常常有人抱怨这样作出来的PDF文件比DjVu大得多。

而从前面的描述来看，DjVu的高压缩比与它的“分层结构、按需编码”有直接关系，而这是能够复制到PDF中来的。所以我认为若是想提升扫描版PDF的压缩率，能够在PDF制做软件上进行改进：引入商业DjVu制做软件的内核或引擎，对须要转换成PDF的扫描图像进行分层，而后按照分层结果选择最有效的图像压缩算法。即把上面说的“图像->DjVu->PDF”过程简化成“图像->PDF”，中间这一步在PDF制做软件内部悄悄完成了。

固然，若是不嫌麻烦，或者有OCR的技术积累，也能够本身去作分层的开发，但最终结果是同样的。其实在我第一次看到用luratech公司的产品制做出来的高压缩比PDF时，我就怀疑他们是这么干的。这也是促使我去写这篇文章的缘由之一。而目前的deent75，也容许用户指定生成的结果文件是DjVu仍是PDF，若是选择PDF，就直接实现了图像转分层PDF。

5.2 反向转换

在讨论完DjVu转PDF后，一个很天然的问题就是：这样转换出来的PDF，能不能再转回DjVu？

我对这个问题的回答是：看你想怎么转。最简单的办法固然是直接打印到DjVu虚拟打印机上，或者找一个现成的PDF2DjVu软件，喜欢折腾的也能够先把PDF转图片，而后图片转DjVu。

不过既然前面说了半天数据格式转换，那我们的思惟仍是别太发散，仍是按照一样的思路：能不能从PDF文件数据流里抽取图像数据流，及层次描述，而后尽可能无损地转换回DjVu？个人回答是：不必定。理由以下：

对于PDF中的JBig2数据流，若是没有半调图像掺合在里面，则与DjVu的JB2数据流具备对应关系，能够无损转回JB2数据流。不过我在PdfToy和UnicornViewer中实现这个过程的时候，碰到了与最初JB2转JBig2同样的问题：转回来的文件长度要比原DjVu文件长度大。从对djvulibre源代码的分析看，这一样也是由于JB2中的“字典二次编码”形成的，不过我实在没有耐心深刻研究，因此采起了一个偷懒的办法：在“导出”界面中增长了一个“二次编码”选项，若是该选项未选中，则用我本身的偷懒方法，即把JBig2中的数据取出来，直接转换成JB2编码，中间不须要全图解码成位图，这个过程能够验证是无损的；不然把全图解码成位图，而后用minidjvu或djvulibre的cjb2，按无损参数从新进行分割、聚类，再编码成JB2，这样出来的结果可能形成字典和页面描述的改变，但全图仍然是无损的，数据流长度也能变小一点。
对于PDF中的JPEG 2000数据，我也没办法直接转换成IW44，并且因为djvulibre中的IW44压缩接口不支持指定压缩率，因此即便解码成位图后从新压缩，也很难保证文件长度不变。
彩色文字方面，若是不从新处理，我也猜不出该用什么方法才能转回去。

所以，我至今也只实现了把PDF中的JBig2导出为DjVu，但不敢去试PDF->DjVu，并且建议各位也别闲来无事转着玩，否则哪天忽然后悔了可没地儿买药去。

反向转换的研究虽然进行得不完全，不过也产生了其余的副产品：在研究过程当中，我感受将来采用JPEG 2000压缩的PDF会增长，所以在UnicornViewer中专门增强了对这方面的支持，而且我名下全部与PDG相关的软件，均开始支持“名为PDG实为JPEG 2000的文件”：若是PDF中的图片实在转不回DjVu，干脆导出成图片看算了。

5.3 PDF浏览器限制

按照我前面说的方法和工具转换出来的PDF采用了JBig二、JPEG 2000压缩，前者要求Acrobat 5以上版本，后者要求Acrobat 6以上版本的浏览器才能正常显示。好在如今主流的Acrobat版本最低也是7。其余常见的PDF浏览器中，PDF-XChange支持这两种格式没有问题，Foxit须要专门的插件，CajViewer则不支持。我本身的UnicornViewer没有问题，在JPEG 2000方面还进行过专门强化，比Acrobat8的兼容性更好。