图像转PDF的问题、方法及题外话

目录
一、需要解决的问题
    1、图像数据流重新压缩造成的问题
    2、阅读的顺畅性问题
    3、对特殊图像格式的支持问题
二、预备知识
    1、PDF支持的图像格式
    2、图像在PDF中的物理表示
    3、图像在PDF中的逻辑表示
三、问题的解决办法
四、小结
五、题外话一：PDF转图像
六、题外话二：除了PDF，还有什么？
    1、多页TIFF
    2、JBIG2
    3、DjVu
    4、双层PDF

一、需要解决的问题

图像转PDF似乎正在成为一个热门话题：对企业或组织来说，随着信息化的深入，需要将大量纸质档案电子化，实现在线查询、共享；对个人来说，随着家用数码相机等的普及，越来越多的人希望将电子图像信息转换成方便浏览、共享的格式。由于PDF文件本身的标准化、方便性，目前在企业和家庭应用越来越多，由此也带动了诸多图像转PDF软件的诞生。 当然“树林子大了，什么样的鸟都有”，至于鸟叫得怎么样，只能实际比较一下再说。

正好由于工作需要，我近期参与了某金融企业的无纸化办公平台建设项目，其中一个重要内容就是将该企业遍布全国的三十余个分支机构积存的巨额（最先开始扫描的一个分支机构就有近三百万页）纸质档案扫描成电子文档。作为项目负责人，我代表客户与国内数家扫描外包公司进行了接触、考察，并对能够搜集到的图像转PDF工具进行了测试、比较，在这个过程中我发现目前图像转PDF软件大致可以分为两类：

• 基于虚拟打印原理。最著名的大概要算Adobe Acrobat Professional、PDF Factory。 基于虚拟打印原理的软件开发门槛稍高一些（需要提供打印驱动程序），所以多为收费软件，通用性较好，除图像文件外还能将Word等所有可打印格式转换成PDF。
• 直接将图像嵌入PDF文件。如ACD Systems出品的ACDSEE中的Create PDF Wizzard、verypdf出品的Image2Pdf等。直接将图像嵌入PDF文件的软件实现相对简单，所以收费、免费的都有。

从测试的结果看，我认为这两类工具普遍存在一些共性问题，包括图像数据流重新压缩造成的问题、生成的PDF文件的阅读顺畅性问题、对特殊图像格式的支持问题等。本文将对这些问题的成因、解决方法加以探讨。

1、图像数据流重新压缩造成的问题

对基于虚拟打印原理实现的转换软件来说，其工作过程为：

• 转换工具提供一个虚拟打印机。如Acrobat提供的打印机名为Adobe PDF。
• 图像浏览软件打开图像文件，在收到打印命令后，象在真实打印机上打印一样，将图像逐象素描绘到虚拟“纸”上，形成发送给虚拟打印机的数据流。
• 虚拟打印机收到数据流后，根据图像的色彩空间等信息，选择“合适”的压缩算法，对数据流再次进行压缩以减小文件长度，然后将压缩后的数据流存入PDF。

为了测试虚拟打印机对图像的处理，我选择了一组图像（用例1），在ACDSEE 8.0 Build 39中打开，选中所有图像，然后选择“File->Print”，打印到Acrobat 7.07提供的PDF虚拟打印机（ACDSEE和PDF打印机的所有参数均为默认值），然后比较原始图像数据和PDF中的图像数据，结果见表1.1。表1.1中各种“解码器”的解释见本文后续的“PDF支持的图像格式”部分，“PDF中的图像数据”各栏中的数据来自开源的PdfView。如果您有兴趣查看PDF文件内部细节，建议用UltraEdit-32，仅看PDF文件结构 用PdfView足矣。

表1.1 从ACDSEE打印图像到Acrobat PDF虚拟打印的结果

原始图像					PDF中的图像数据
序号	说明	宽×长 （象素）	图像解码器	文件长度 （字节）	PDF解码器	BitsPerComponent /ColorSpace	数据流长度 （字节）
01	黑白TIFF	1728×1103	CCITT G3	50,401	CCITT G4	1/ICCBased	54,329
02	黑白TIFF	3315×2334	CCITT G4	35,518	CCITT G4	1/ICCBased	36,110
03	彩色JPEG格式TIFF	512×384	DCTDecode	24,428	DCTDecode	8/ICCBased	21,753
04	灰度JPG	445×600	DCTDecode	34,167	FlateDecode	8/Indexed	200,404
05	彩色JPG	1024×768	DCTDecode	102,776	DCTDecode	8/ICCBased	71,540
06	16级灰度GIF	800×1199	LZWDecode	124,738	FlateDecode	4/Indexed	128,925
07	256色GIF	130×129	LZWDecode	8,408	FlateDecode	8/Indexed	6,990
08	黑白PNG	32×32	FlateDecode	164	CCITT G4	1/ICCBased	41
09	2色彩色PNG	32×32	FlateDecode	112	FlateDecode	1/ICCBased	21
10	256级灰度PNG	600×905	FlateDecode	289,059	FlateDecode	8/Indexed	286,947
11	16级灰度PNG	720×1053	FlateDecode	74,322	FlateDecode	4/Indexed	74,943
12	24位色PNG	350×560	FlateDecode	72,107	FlateDecode	8/ICCBased	79,351
13	15位色BMP	260×235	未压缩	122,266	DCTDecode	8/ICCBased	5,783
14	16色BMP	940×20	RLE	8,134	FlateDecode	4/Indexed	2,868
图像文件总长度（字节）			946,600		PDF文件总长度（字节）		989,431

注1. 图像01.tif经ACDSEE转成PDF后，图像 物理表示的高度变成2206，原因 后面会加以解释。
注2. 对于索引色（Indexed）图像，“数据流长度”仅包含图像数据流长度，不包含索引（调色板）数据流长度。严格说来这会造成一些误差，但影响不大。以下各表与此相同，不再特殊说明。

从表1.1可以看出，对于ACDSEE发送过来的数据流，Acrobat PDF虚拟打印机进行如下处理：

• 黑白图像重新压缩为CCITT G4数据流。
• 灰度、索引色（调色板）图像压缩为Flate（ZIP）数据流，色深（BitsPerComponent）不变。
• 非索引色（如15位色、24位色）图像压缩为DCT（JPG）或Flate数据流。似乎Acrobat PDF虚拟打印机能自动识别压缩为哪种数据流更有利，但压缩成JPG数据流时似乎质量系数很低：文件更小，质量更差。
• 考虑跨平台特性，所有色彩均表示为ICCBased，并给出对照表。

这种处理带来的问题是：

• 对于有损压缩的灰度JPG，转换后就成了无损压缩的数据流，必然导致文件长度的膨胀。
• 对于原来无损压缩的彩色图像（PNG、BMP），转换后可能成为有损压缩的JPG数据流，造成图像质量下降（从转换后的数据流长度看，重新压缩的JPG质量系数不会太高）。对于原来就是有损压缩的彩色JPG图像来说，由于是解码后再压缩，图像质量将会逐次衰减。

为了确认是否所有软件在使用虚拟打印机转换PDF时，均会对JPG图像进行再压缩，我进行了第二个试验：在Word 2003中插入用例1中的13张图像（Word 2003不支持03.tif），每张图像前面再插入一点文字（图像编号），然后打印到Acrobat PDF虚拟打印。限于篇幅，这里不列举具体结果（用例1是公开的，Word 2003、Acrobat也不难找，想要较真的人可以自己动手试一下），仅说明结果：

• 对01、02两个TIFF文件，Word转换成CCITT G4压缩，而且01.tif物理表示的高度未变，这 比ACDSEE强。但是这两个图像均被分解成了多个对象（01.tif分成2个，02.tif分成8个），相当于将原始图像切割成多个水平横条，每个对象代表一条。
• 对04、05两个JPG图像，Word将原始文件完整地嵌入了PDF文件，但在结尾添加了一个/r（0AH）字符。显然，Word并没有对原始JPG文件进行解码、再压缩。
• 对06、07两个GIF文件，Word打印后均成为ZIP数据流，与ACDSEE相似。
• 对08、09两个PNG文件，Word打印后成了4位索引色图像（BitsPerComponent＝4，Indexed），压缩算法仍然为ZIP。10～12三个PNG文件转换结果与ACDSEE相似。
• 13、14两个BMP文件转换结果与ACDSEE相似。

从转换结果的对比来看，Word和ACDSEE的打印结果在TIFF、JPG、PNG方面存在较大差距：

• 对于