原本图像数据和PDF中的图像数据

原本图像数据和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方面存在较大差异:

  • 对此TIFF图像,Word对图像实行了切割,这么些估算与Word对图像的突显形式有关;别的Word没有改变图像的物理表示
    那与下部要谈的“直接将图像嵌入PDF文件”的转移软件接近。
  • 对于JPG图像,Word没有再压缩的经过,由此不会造成图像质料的衰减。
  • 对于PNG图像,Word就好像有友好的代表方法,存在解码、重新回落的经过,并且将BitsPerComponent小于4的PNG转换成BitsPerComponent等于4的图像,那一点与CxImage很象。

汇总,对于基于虚拟打印原理完成的图像转PDF工具,可能会设有如下问题:

  • 对此有损压缩的JPG文件,转换成PDF后的质地与发出打印命令的软件密切相关。如象ACDSEE那样先解码再打印,必然会因为图像的再压缩而致使质料衰减或文件膨胀。而象Word那样直接将JPG数据流发送到虚拟打印机,则与软件内部的打印设置有关,设置好了足以一贯将数据流完整嵌入PDF而不造成损失或暴涨,设置不佳则一律可能引致损失。其它打印机对JPG数据流的支撑受平台限制,我猜这就是为什么包罗ACDSEE在内的大部软件宁愿先解码后打印的来由:解码成bitmap再打印可以不受平台限制。
  • 对于无损压缩的图像文件,如GIF、PNG、BMP等,真彩图像往往会被转换成有损压缩的JPG数据流,造成图像质地损失;灰度、索引色图像往往会被解码后再压缩成某种无损压缩数据流,倘若虚拟打印机所选压缩算法的压缩效低于原图像压缩算法,则可能造成PDF文件的暴涨。

直接将图像嵌入PDF的更换软件工作原理与基于虚拟打印机的变换软件分歧,其工作经过为:

  • 用户在转换软件中选择要求转移的图像文件。
  • 转换工具根据PDF文件规范始建PDF文件,写入文件头新闻。
  • 改换工具逐一从图像文件中抽取图像数据,视须求对数据开展转换,然后将数据打包成PDF对象,写入PDF文件。
  • 改换工具写入PDF文件尾,打包截至。

为了测试图像嵌入式转换工具的效应,我将与表1.1如出一辙的图像文件(用例1),
用ACDSEE 8.0 (Build 39)的Create PDF
Wizzard转换成PDF,结果见表1.2

表1.2 ACDSEE 8 PDF创造插件转换结果

本来图像

PDF中的图像数据

序号

说明

宽×长
(象素)

解码器

文本长度
(字节)

解码器

BitsPerComponent
/ColorSpace

数量流长度
(字节)

01

黑白TIFF

1728×1103

CCITT G3

50,401

DCTDecode

8/DeviceGray

905,917

02

黑白TIFF

3315×2334

CCITT G4

35,518

DCTDecode

8/DeviceGray

693,129

03

彩色JPEG格式TIFF

512×384

DCTDecode

24,428

DCTDecode

8/DeviceRGB

34,496

04

灰度JPG

445×600

DCTDecode

34,167

DCTDecode

8/DeviceGray

59,338

05

彩色JPG

1024×768

DCTDecode

102,776

DCTDecode

8/DeviceRGB

129,655

06

16级灰度GIF

800×1199

LZWDecode

124,738

DCTDecode

8/DeviceRGB

319,743

07

256色GIF

130×129

LZWDecode

8,408

DCTDecode

8/DeviceRGB

6,706

08

黑白PNG

32×32

FlateDecode

164

DCTDecode

8/DeviceGray

936

09

2色彩色PNG

32×32

FlateDecode

112

DCTDecode

8/DeviceRGB

896

10

256级灰度PNG

600×905

FlateDecode

289,059

DCTDecode

8/DeviceGray

185,845

11

16级灰度PNG

720×1053

FlateDecode

74,322

DCTDecode

8/DeviceGray

206,121

12

24位色PNG

350×560

FlateDecode

72,107

DCTDecode

8/DeviceRGB

38,468

13

15位色BMP

260×235

未压缩

122,266

DCTDecode

8/DeviceRGB

8,209

14

16色BMP

940×20

RLE

 8,134

DCTDecode

8/DeviceRGB

22,018

图像文件总长度(字节)

946,600

PDF文件总长度(字节)

2,619,592

表1.2中得以看出,ACDSEE
8.0 (Build 39)的Create PDF Wizzard对图像的转换原则是:

  • 灰度图像一律转换成灰度JPG数据流。
  • 彩色图像一律转换成彩色JPG数据流。

看来ACSEE对它的JPG转换引擎还真不是一般地有信念!但从表1.2所列数据看,这种转移也不是从未有过问题:

  • 对于是非图像,CCITT
    G4的缩减比平日比灰度JPG高许多,毕竟它是专为压缩黑白图像而研发的压缩算法。因而将CCITT
    G3/G4转换成灰度JPG无疑将会造成文件膨胀,而且膨胀得很显明。那一点对电子文档来说比较重大:半数以上清楚的纸质文档扫描后都是黑白图像。
  • 对此低色深(如16级灰度)图像来说,转换成灰度JPG(256级灰度)同样可能造成文件膨胀。
  • 对于自然就是JPG压缩格式的图像,用ACSEE转换后也会产出文件膨胀的题目,莫非是ACSEE转换插件用的JPG质量全面比较高?
  • 无论是原来的图像格式是怎么样,经过ACSEE的变换插件转换后总体解码再重复压缩成有损的JPG数据流,无疑会对图像质量造成损伤。

ACSEE的转换插件效果很令我失望,为了相比较其余嵌入式工具的更换职能,我又用用例1测试了verypdf的Image2Pdf
v1.7,转换结果见表1.3

表1.3 Image2Pdf转换结果

原本图像

PDF中的图像数据

序号

说明

宽×长
(象素)

解码器

文件长度
(字节)

解码器

BitsPerComponent
/ColorSpace

数码流长度
(字节)

01

黑白TIFF

1728×1103

CCITT G3

50,401

CCITT G4

1/DeviceGray

41,638

02

黑白TIFF

3315×2334

CCITT G4

35,518

CCITT G4

1/DeviceGray

34,981

03

彩色JPEG格式TIFF

512×384

DCTDecode

24,428

DCTDecode

8/DeviceRGB

32,815

04

灰度JPG

445×600

DCTDecode

34,167

DCTDecode

8/DeviceGray

34,167

05

彩色JPG

1024×768

DCTDecode

102,776

DCTDecode

8/DeviceRGB

102,776

06

16级灰度GIF

800×1199

LZWDecode

124,738

RunLengthDecode

4/Indexed/DeviceRGB

206,880

07

256色GIF

130×129

LZWDecode

8,408

RunLengthDecode

8/Indexed/DeviceRGB

13,380

08

黑白PNG

32×32

FlateDecode

164

FlateDecode/PNG

1/DeviceGray

91

09

2色彩色PNG

32×32

FlateDecode

112

FlateDecode/PNG

1/Indexed/DeviceRGB

21

10

256级灰度PNG

600×905

FlateDecode

289,059

FlateDecode/PNG

8/DeviceGray

288,582

11

16级灰度PNG

720×1053

FlateDecode

74,322

FlateDecode/PNG

4/Indexed/DeviceRGB

74,063

12

24位色PNG

350×560

FlateDecode

72,107

FlateDecode/PNG

8/DeviceRGB

71,954

13

15位色BMP

260×235

未压缩

122,266

DCTDecode

8/DeviceRGB

8,707

14

16色BMP

940×20

RLE

 8,134

DCTDecode

8/DeviceRGB

20,890

图像文件总长度(字节)

946,600

PDF文件总长度(字节)

942,458

表1.3看,Image2Pdf对图像数据的处理要比ACDSEE的PDF创造插件智能得多:

  • 对于黑白TIFF文件,可以活动压缩成CCITT G4;彩色TIFF解码后回完结JPG。
  • 对于JPG文件,根本就从未解压、再压缩的历程,直接将原始JPG文件一个字节不改就停放PDF文件,从而避免因为重新回落而招致质量衰减,而且解压、再压缩的时日也省了。
  • 对于GIF文件,解压后减去为RLE(行程编码)。由于RLE的压缩率远不如GIF本身的LZW算法,由此那种再压缩会导致文件膨胀。预计那种吃力不讨好的做法与神话中LZW压缩算法的版权有关。
  • 对于PNG文件,数据流压缩算法不变(PNG压缩算法在PDF中对应/DecodeParms[<</Predictor
    15>>]
    ),但数量流长度会稍小部分,推断是去掉了PNG文件中的无关信息。
  • 对此彩色BMP文件,全体再一次回达成JPG数据流,在情调数较多、色调过渡自然时亦可减小文件长度,否则会大增文件长度。当然不论哪类状态画面质量都会损失。

其余图像转PDF的软件本身还试过一些,可是基本与上述三种工具类似,都可能因为对图像数据流重新回落而发出一些问题,差距只在题材的多与少、严重与不严重:

  • 将无损压缩转换成有损压缩,或对有损压缩解码后再次有损压缩,必然导致图像质料下滑。
  • 更改文件数据流的压缩方法,在一些景况下得以减小文件长度,在好几情状下则会造成文件长度膨胀。关键是看数量与裁减方法的陪衬是还是不是方便。
  • 对于一直读取图像数据的转移工具,由于可以从原来图像文件中得到丰裕的图像音讯,包罗原始数据压缩算法等,由此可以针对差距的文件格式或分歧的图像情形做出取舍;基于虚拟打印原理落成的更换工具,如果打印机只好获取解码后的数据流,选用的余地就会小一些:只可以从bitmap数据流中得到色深等音讯,然后自行选用算法重新回落数量。

2、阅读的顺畅性问题

此处说的读书顺畅性问题,是指:

  • 一经PDF纸张接纳A4、B5等规范纸张,而原本图像的长宽比例与所选纸张的长宽比例不相同,必然会在前后或左右出现较多空白,影响阅读。
  • 如若PDF纸张随图像大小而变化,则转移出来的页面可能大小不一,在阅读时感到页面跳来跳去,万分不爽。

对于第四个问题,近来从未有过什么好的化解方案。对于首个问题,可能的缓解方案包涵:

  • 提出用户在翻阅时将PDF
    里德r设置为单页、适合宽度,那样每一页都会自动缩放到Reader的窗口宽度。如若嫌麻烦,也得以在生成PDF时就指定“开端视图”中的“页面布局”为“单页”,“放大率”为“适合宽度”。那种办法的缺点是上下翻页时不如“三番五次”形式顺畅。
  • 在生成PDF文件时为页面指定一个原则性宽度,页面的长短根据原来图像的长宽比自动伸缩。那种方法能保险在以“屡次三番”方式阅读时页面不会跳来跳去,当然打印出来依旧会在纸张的左右或左右发生空白。

3、对更加图像格式的支撑问题

那里说的“特殊图像格式”,其实根本就是TIFF格式。在科普的图像格式中,JPG、GIF、PNG、BMP等都有严厉的格式规定,可以公布的退路不多。但是对于TIFF来说,由于专业本身希望可以容纳尽可能多的事物,可是对贯彻细节尚未交给具体的规定,所以各家软件生成的TIFF文件五花八门,令人胃痛。

以自己提供的测试用例2为例,那个其实是永葆TIFF文件最高贵的开源项目libtiff
3.7.1版所带测试图片,不过去掉了一张caspian.tif(该图片共3通路,单通道采样位数高达64位浮点数,我的32位真彩显示屏单通道采样位数唯有8位整数,突显不断这么高级的图片)。但仅凭剩下的这几个图片,已经得以难倒包罗verypdf的Image2Pdf在内的一大批图像转PDF软件,固然是ACDSEE这样“专业”的图像浏览器,5.0.1版在看这么些图像时也会并发比例失调(fax2d.tif、g3test.tif)、看不住(quad-tile.tif)、颜色失真(smallliz.tif、zackthecat.tif)等题材;8.0版尽管校正了上述问题,但又出新新的题目:看dscf0013.tif时颜色失真。

实在那些文件还算好,毕竟是libtiff团协会提供的,至少它和谐的源代码还可以解出来。但在自我接触到的境内正式扫描外包集团中,一大半供销社提供的TIFF文件只要接纳了有损压缩,多半就连libtiff也解不开,ACDSEE更是想都不要想。有些如故连专门彰显TIFF文件的Microsoft
Office Document Imaging(微软Office 2003所带附件之一)都解不开。

不巧由于工作急需,我必须和这个怪异TIFF文件打交道。我想到的出路包涵:

  • 决不在TIFF文件中应用有损压缩,更加不要用各品牌专业神速扫描仪所带扫描软件生成有损压缩TIFF文件。由于历史原因,这么些软件遵从的多数是古老的TIFF标准,生成的文本大致只有它们自己的翻阅软件能打开。倘使有必要对图像举行有损压缩,直接存储为业内JPG格式即可,这些很难玩什么花样。
  • libtiff源代码为底蕴,针对这么些图像不正规的地点,稳步更正libtiff代码。那就是干吗前段时间我自己写的ComicEnhancer
    Pro
    直接在进步的原由。我竟然质疑,可能就是因为TIFF格式支持起来太难为,所以IE才不支持。

除TIFF外,PNG文件也是一种可能会造成地下麻烦的格式。然则与TIFF分歧,PNG的难为不在于文件格式本身或数据压缩算法,而介于它助长的情调表示:PNG扶助灰度、索引、彩色、Alpha通道彩色图像,并且色深除低端的1、2、4、8位外,还帮衬16位色深。有趣味又欣赏较真的人,可以到libpng下载一份libpng源代码,里面的contrib\pngsuite文件夹下就包蕴了一堆图片,专门用来测试软件对PNG色彩支持的能力。

从自身测试的结果看,软件在处理PNG图像时或许现身的题目包含:

  • 将16位色深简化成8位色深。这一个在日常24位/32位屏幕上看不出问题,因为那些显示屏最三只接济8位色深,不过未来高端展现开销下落后恐怕就会被人见到不同了。PDF文件也是从PDF
    1.5版(Acrobat 6.0)初阶才支撑16位色深。
  • 对此低色深(BitsPerComponent <
    4)的PNG图像,转换成BitsPerComponent=4的索引色图像,造成一线的文本膨胀。

归咎,近日图像转PDF工具普遍存在一些共性的题目,包蕴图像数据流重新回落造成的问题变迁的PDF文件的读书顺畅性问题对良好图像格式的支撑问题等。为了更好地了然那一个题材,并找到解决办法,下边先简单介绍一下PDF中与图像相关的基本概念。

二、预备知识

事先注明:本有的持有情节均出自Adobe集团发表的《PDF Reference 5th
edition》

说白了就是本人看那份文档时做的笔记的一局地,所以看起来也许有点无头无尾,各位看得懂就看,看不懂就去看《PDF
Reference 5th
edition》
原文吧。

1、PDF帮助的图像格式

在PDF文件中,图像点阵消息以减弱数据流的样式存在,PDF通过过滤器(filter)对数据流解码。在《PDF
Reference 5th
edition》
中,共介绍了十种过滤器,其中与图像相关的如表2.1所示。

表2.1 PDF文件接济的图像过滤器

过滤器名称 对应压缩算法通称 对应图像格式 压缩类型 说明
LZWDecode LZW GIF、TIFF 无损 通常用于索引色(调色板)图像
FlateDecode ZIP PNG、TIFF 无损 除图像外,也用于文本压缩
RunLengthDecode RLE BMP、TIFF 无损 通常用于单色图像
CCITTFaxDecode G3/G4 TIFF 无损 专为黑白图像研发的高效压缩算法
JBIG2Decode JBIG2 JBG 无损 专为黑白图像研发的高效压缩算法
DCTDecode JPEG JPG、TIFF 有损 用于256级灰度、24位真彩自然图像
JPXDecode JPEG2000 J2K、JP2 有损/无损 JPEG的最新标准,压缩比与质量并重

表2.1看,其实对半数以上广大图像格式,都得以将原数据流间接嵌入PDF文件,不须要再另行编码。当然某些数据,如JPG文件中的注释、PNG文件的文件头/文件尾,在PDF文件中没用,可以先剔除再将剩余部分嵌入PDF文件。而对于TIFF文件,必要针对现实压缩算法,将真正图像数据抽取出来再放到PDF文件。

直白选择原来数据流而不再另行编码,不仅可以节省图像转换成PDF的年月,而且对于有损压缩,可以避免因为一再压缩而导致图像质地的衰减。可是对于GIF格式的LZW压缩来说,情形有点复杂:由于Unisys集团评释对LZW算法拥有专利权,导致众多软件,包罗名满天下的xpdf在内,屏弃对LZW的支撑,改用开源的Flate压缩算法。Flate其实是Winzip等软件应用的ZIP压缩算法的此外一个名字。《PDF
Reference 5th
edition》
中对那三种算法的叙说如下(甲骨文效果是自家自己加的):

Because of its cascaded adaptive Huffman coding, Flate-encoded output
is usually much more compact than LZWencoded output for the same
input
. Flate and LZW decoding speeds are comparable, but Flate
encoding is considerably slower than LZW encoding.

是因为上文中小篆部分的描述,及许多铺面、社团卷入与Unisys的专利纠纷,由此在自我见状的图像转PDF工具中,没有选拔LZW压缩算法的,都宁愿将用LZW压缩的GIF图像解码后再压缩成Flate数据流。那种转移在超过半数情状下能获取更好的压缩比,但分歧总是有些(所以上文用的词是usually,而不是always),如用例1中的06.gif,LZW就比ZIP有效得多,那样的图样我还有几张,不过限于篇幅和空中,就不节外生枝了。

对于LZW和Flate压缩,PDF还匡助预先报告器(Predictor),预先报告器表示按照图像的某些特征,先对图像进行一些预处理后再对处理结果进行削减,以取得更高的压缩比。在《PDF
Reference 5th
edition》
中定义的预先报告器见表2.2。小于10的预告器称TIFF预告器,源自libtiff;10以上的称PNG预告器,源自libpng。由此只要PDF文件中定义图像的大体表示时行使了Predictor属性,多半可以猜到原始图像的格式。
表3.1和表1.3中,为了更好地开展相比,采取PNG预告器的Flate解码器均标注为FlateDecode/PNG。

表2.2 预报器

预报器值 含义
1 No prediction (the default value)
2 TIFF Predictor 2
10 PNG prediction (on encoding, PNG None on all rows)
11 PNG prediction (on encoding, PNG Sub on all rows)
12 PNG prediction (on encoding, PNG Up on all rows)
13 PNG prediction (on encoding, PNG Average on all rows)
14 PNG prediction (on encoding, PNG Paeth on all rows)
15 PNG prediction (on encoding, PNG optimum)

2、图像在PDF中的物理表示

一幅图像在PDF文件中一般用一个XObject对象表示(某些TIFF图像可能要用八个目的表示),那么些目的描述图像的原始象素点阵音讯,因为那几个点阵音信由爆发图像的设施本身的情理属性(如扫描仪的DPI、
单反的卓有功用象素数等)决定,因而在那边名为图像的大体表示,在《PDF
Reference 5th
edition》
中又称之为采样表示(山姆ple
Representation)。

要描述图像的情理表示,需求提供下列新闻:

  • 图像的宽度(width),以象素为单位。
  • 图像的万丈(height),以象素为单位。
  • 每象素的颜色通道数,或色彩空间(The number of color components per
    sample, ColorSpace)。
  • 每通道的采样位数(The number of bits per color component,
    BitsPerComponent)。
  • 图像象素点阵数据流(stream)。
  • 解码图像数据流所需的过滤器(Filter)名称,及过滤器选择的预先报告器(Predictor)。

用例1为例,在ACDSEE
8
PDF创造插件转换的PDF中,用如表2.3所示的XObject定义第二
幅图像(数据来源PdfView,左边双斜杠前面是自个儿要好加的笺注):

表2.3 图像对象定义实例

9 0 obj
<<
/Type /XObject
/Subtype /Image
/Name /Image90
/Width 3315
/Height 2334
/BitsPerComponent 8
/ColorSpace /DeviceGray
/Filter [/DCTDecode]
/Length 693129
>>
stream
……
endstream
endobj
// 对象定义开始,对象ID为9
// 字典(dictionary)定义开始
// 对象类型为XObject
// 对象子类型为图像
// 对象名称Image90
// 图像宽度3315象素
// 图像高度2334象素
// 每通道采样位数为8
// 色彩空间为256级灰度
// 解码过滤器为JPG(参见表2.1
// 数据流长度693129字节
// 字典定义结束
// 数据流开始
// 数据流内容,一串16进制数,此处从略
// 数据流结束
// 对象定义结束

PDF中的每个对象均有一个ID(编号),通过对象ID,可以对目标自我举办引用。如一个LOGO图像可能作为背景出现在每一个页面上,在每一页中从不必要都带有那个LOGO图像的莫过于数据,只要引用那个LOGO图像的ID即可。那样确实可以增进PDF文件的仓储效能。上例中图像的目的ID就是9。

3、图像在PDF中的逻辑表示

前面说的图像的大体表示是用象素点来表示图像,然则只要一贯根据象素点对图像举行显示、打印,可能会现出问题。以用例1中的第二
幅图像为例,象素点阵为3315×2334,要是在分辨率为96
DPI的显示屏上显得,尺寸是34.5英寸×24.3英寸(1英寸=2.54分米,实际英寸数=象素数÷DPI,如3315÷96=34.5英寸),而在分辨率为300
DPI的打印机上打印,打出来只有11.1英寸×7.8英寸,这明确与PDF要求的“在此外平台上均可获取同样的机能”不符。由此在用物理表示定义出图像的象素点阵后,在其实要求出示图像的地点,不仅要交给图像大体表示的靶子ID,还亟需付出图像的逻辑表示,包含:

  • 图像的逻辑尺寸。这几个尺寸的单位是1/72英寸,因而是一个逻辑概念,即无论是在如何的设备上输出图像,图像的分寸都是固定的英寸值,而不会趁着输出设备的DPI值而转变。
  • 图像的偏移量,即图像左上角点距离页面左上角点的距离,那等同是一个与设备的情理分辨率非亲非故的逻辑量,单位为1/72英寸。
  • 图像的旋转角度。

那种物理与逻辑表示的诀别,能够带动一些便宜:

  • 一律份物理数据,可以在不相同的地方、用分歧的分寸、以分歧的转动角度开展展示。
  • 由此将物理表示映射成逻辑表示,能够脱离设备的物理性能限制,在不一样的配备上获取一致的作用。

实际到PDF文件格式上,在一个页面上显得一幅图像,除了前面说过的图像的物理表示对象外,还要求定义页面(Page)对象,然后在Page对象中:

  • 用MediaBox属性定义页面的逻辑大小,单位为1/72英寸。
  • 用Resources属性定义页面中包涵的资源,即眼前说的图像物理表示的对象ID。
  • 用Contents属性定义资源对象(图像)的逻辑表示。

Contents属性日常定义一个六元组,表示为[a, b, c, d, e,
f],则从图像物理坐标(x, y)映射为逻辑坐标(x’,
y’)的炫耀关系可以表示为如下矩阵运算:

    a b 0  
  [x’ y’ 1] = [x y 1] × c d 0       式 2.1
    e f 0  

或意味着为如下分析表明式:

  x’ = ax + cy + e                 式 2.2
  y’ = bx + dy + f            

从《计算机图形学》知识可以,式2.1式2.2中参数a、d分别为x、y向比例周到,完成从物理尺寸到逻辑尺寸的照耀;c、b为旋转全面,表示图像彰显时的团团转角度;e、f为平移周到,表示图像到页面左上角的偏移量。

用例1为例,在ACDSEE
8
PDF成立插件转换的PDF中,用如表2.4所示的构造定义第二页。

表2.4 页面对象定义实例

8 0 obj
<<
/Type /Page
/Parent 3 0 R
/Contents 7 0 R
/MediaBox [0 0 3315 2334]
/Resources <</ProcSet [/PDF /ImageC] /XObject <</Image90 9 0 R>>>>
>>
endobj
// 对象定义开始
// 字典定义开始
// 对象类型
// 父对象
// 内容在对象7定义
// 页面大小
// 页面包含的图像
// 字典定义结束
// 对象定义结束

情节对象7中定义了图像对象的逻辑表示,如表2.5所示。

表2.5 图像对象的逻辑表示实例

7 0 obj
<<
/Length 38
>>
stream
q
3315 0 0 2334 0 0 cm
/Image90 Do
Q
endstream
endobj
// 对象定义开始
// 字典定义开始
// 数据流长度38字节
// 字典定义结束
// 数据流开始
// 保存图像状态(Save graphics state)
// 式2.1座标映射所需的六元组(Coordinate transformation Matrix)
// 绘制映射后的图像(Paint image)
// 恢复图像状态(Restore graphics state)
// 数据流结束
// 对象定义结束

表2.5的六元组参数看,ACDSEE
8
PDF创制插件用一种很偷懒的主意协会该六元组:直接用图像的情理象素尺寸作为逻辑尺寸。由于显示器DPI常常为96
DPI,而PDF为72 DPI,那种偷懒造成的结局就是图像在PDF
Reader中遵从“实际尺寸”显示时,看起来会比在ACDSEE中按照“完整大小”显示更大一部分。精确一点说,那张图片在PDF中的“实际尺寸”达到了46.04英寸×32.42英寸。其中46.04=3315÷72,32.42=2334÷72。

对此喜欢较真的人的话,ACDSEE的那种偷懒造成了更深层次的失真:用例1中的第二幅图像是一张扫描形成的TIFF图像,在TIFF文件结构中记载了围观时扫描仪使用的DPI值——200
DPI。在ACDSEE
8中打开此图像文件,点击“文件->属性”菜单,在展现出来的文件属性中即可知到扫描DPI,及依照扫描DPI换算,这张图片对应原始纸质页面的深浅——16.57英寸×11.67英寸。那么些尺寸与46.04英寸×32.42英寸比较,实在是差得太远了少数。

而如若用verypdf的Image2Pdf
v1.7对同样张图片进行转移,可以观望转换后的PDF页面大小为16.57英寸×11.67英寸,即在PDF
里德r中选拔根据“实际尺寸”举办显示,突显出来的图像大小,正好与原始纸质文件的分寸相同。明显那样的结果更切合文档电子化的渴求和习惯。

Image2Pdf的那种“保真”转换进程可以描述如下:

  • 若是图像文件中著录了扫描时扫描仪的DPI设置,则先依照“英寸数=象素数÷扫描DPI”,总计出图像的原始尺寸,以英寸为单位。
  • 按照“PDF尺寸=英寸数×72”,将以英寸为单位的图像原始尺寸转换成PDF中的逻辑尺寸,并据此填写六元组。

三、问题的解决办法

在询问了相关准备知识后,再回看前边提到的图像转PDF须求直面的问题,其答案自然明了:

  • 图像数据流重新回落造成的问题:对有损压缩图像数据,应竭尽将原本数据流嵌入PDF文件,避免再一次回落造成图像质地衰减;对无损压缩图像数据,可以依据图像特点选用适合的无损压缩算法重新回落图像数据,以节省存储空间,也得以一向将原始图像数据嵌入PDF,以节约重新回落所需的小运。
  • 阅读的顺畅性问题:提供灵活多样的页面布局供用户按需接纳,包蕴固定纸张大小、固定纸张宽度、根据图像大小定制页面等。页面大小的不一样不应对本来图像数据流(图像的大体表示)造成影响,而是经过定义图像的逻辑表示,由PDF
    里德(Reade)r本身来形成须求的图像缩放工作。
  • 破例图像格式的协理问题:这一个题材靠等待很难等到结果,最简单易行的法子就是投机去面对、解决。

简单来讲,对于象我那样有特殊需求的人来说,在当下的动静下要想博得满足的结果,仍然不得不促成“人要靠自己”的口径。当然也绝非要求重新发明轮子,在我看来最精良的图景就是可以在存活开源项目基础上,通过须要的改动和补充,就能落成自我的渴求。可是google的结果令自己多少有点惊叹:尽管眼下最高贵的图像codec开源项目都是基于C的,包罗JPEG
LIB
libpnglibtiff等,但是偏偏在PDF生成领域,JAVA就像比C多,包涵iText等一大批开源项目,而C唯有PDFlibClibPDFPanda等有数的多少个。

ClibPDF从参考手册上看,在绘图等效果方面很有特点,可是对于图像文件的支撑较差,而且要付钱,所以我粗看了弹指间,没有深究。

Panda的法力、接口都丰富简洁,生成的PDF文件也没多少费话,所以自己花时间详细试了一晃。结果发现一个小小小缺点:它的内存漏洞其实是太多
了点,补都补可是来,最终不得不舍弃。

对照,PDFlib堪称内容丰裕、功效强大,某些高级效率(web优化、权限决定等)就算要付钱才能收看,但就是是免费开源出来的PDFLib
Lite,对于各样图像格式的协助也丰裕日常使用了,而且基本上没什么显明的内存漏洞。由此我在DACapturer中试用了一把。可是在采纳一段时间后就意识一些题材:

  • PDFLib的强有力其实是和它代码的复杂程度分不开的,想对如此的代码做更改,实在太麻烦了。
  • PDFLib生成的PDF文件中废话太多,导致文件膨胀。DACapturer对此不是很在乎,可是在急需处理的公文数以万、十万做单位的事务系统中就要求考虑了。
  • PDFLib对JPG、PNG的支撑很好,但是对TIFF的支撑可以用“令人切齿”来描写:不支持JPEG/OJPEG压缩的TIFF还足以弥补(俺在DACapturer中经过在PDFLib
    Lite之外打补丁的法子解决),不过将TIFF中的每个strip当作一个目的来处理,就有点过分了,甚至发出过如此的事:用PDFLib转换十几页TIFF成为PDF,居然在PDF中创立了几千个obj,后来用iText对这么的PDF文件举行联合操作,
    甚至活活把iText拖垮了。所以用了没多长期,俺就下定狠心一定要和PDFLib说再见。

是因为问题的根子出在TIFF文件上,所以自己的眼光很快集中到llibtiff源代码中涵盖的tiff2pdf.c。那份代码是我见过最精简的PDF生成代码,而且由于是libtiff友善提供的,丢三拉四算是出身豪门、血统纯正,对TIFF文件的支撑当然很惊人,我哪怕用它弥补了PDFLib不协理JPEG/OJPEG压缩TIFF文件的问题。当然那份代码也不是少数题材没有:

  • 为了节约内存消耗,生成PDF时行使了一种很少见的一一,导致在变幻不测进程中难以动态增进新的图像。
  • 对JPEG/OJPEG、CCITT
    G3/G4、zip压缩的TIFF帮衬很好,不过对其余格式TIFF的支撑有待加强,用用例2测试一下就明白了。

好在那份代码比较简单,结构中规中矩,改起来不是太难。最后自己以它为底蕴落成了新版图像转PDF内核,并组成大名鼎鼎的CxImage,将对图像格式的支撑从TIFF增加到了JPG、PNG、BMP和GIF,成为公开发行的免费软件FreePic2Pdf,可以落成:

  • 对有损压缩的jpg文件及运用JPEG/OJPEG算法压缩的TIFF文件,能直接将原始JPEG数据流嵌入PDF文件,幸免因为重新采样而造成图像质料下跌。
  • 对此无损压缩的图像文件,黑白图像解码后收缩为G4,其它解码后压缩成ZIP数据流嵌入PDF文件。纵然解码/压缩须要用度一些时辰,不过在大部意况下得以减小PDF文件长度。
  • 可以指定生成的PDF文件的页面大小(除A4、B5等,还辅助国内常用的32开、16开、大32开)及页边距,那种指定不会改变图像的物理表示,只影响PDF中对图像的逻辑表示
  • 如若不点名页面的纸张大小,可以指定页面的永恒宽度(长度随图像大小伸缩),保险屡次三番阅读时不会因为页面宽度变来变去而影响阅读。
  • libtiff源代码举行了变动,以尽力而为帮衬种种新鲜格式的TIFF文件;直接调用libpng对PNG图像举办拍卖,以匡助更加色深的PNG文件。

用FreePic2Pdf对用例1开展转移,结果见表3.1

表3.1 FreePic2Pdf转换结果

原始图像

PDF中的图像数据

序号

说明

宽×长
(象素)

解码器

文本长度
(字节)

解码器

BitsPerComponent
/ColorSpace

数据流
长度
(字节)

01

黑白TIFF

1728×1103

CCITT G3

50,401

CCITT G4

1/DeviceGray

41,638

02

黑白TIFF

3315×2334

CCITT G4

35,518

CCITT G4

1/DeviceGray

34,981

03

彩色JPEG格式TIFF

512×384

DCTDecode

24,428

DCTDecode

8/DeviceRGB

23,169

04

灰度JPG

445×600

DCTDecode

34,167

DCTDecode

8/DeviceGray

34,167

05

彩色JPG

1024×768

DCTDecode

102,776

DCTDecode

8/DeviceRGB

102,776

06

16级灰度GIF

800×1199

LZWDecode

124,738

FlateDecode

4/Indexed/DeviceRGB

126,407

07

256色GIF

130×129

LZWDecode

8,408

FlateDecode

8/Indexed/DeviceRGB

7,031

08

黑白PNG

32×32

FlateDecode

164

CCITT G4

1/DeviceGray

40

09

2色彩色PNG

32×32

FlateDecode

112

FlateDecode

1/Indexed/DeviceRGB

17

10

256级灰度PNG

600×905

FlateDecode

289,059

FlateDecode

8/DeviceGray

278,021

11

16级灰度PNG

720×1053

FlateDecode

74,322

FlateDecode

4/Indexed/DeviceRGB

73,199

12

24位色PNG

350×560

FlateDecode

72,107

FlateDecode/PNG

8/DeviceRGB

71,954

13

15位色BMP

260×235

未压缩

122,266

FlateDecode/PNG

8/DeviceRGB

31,764

14

16色BMP

940×20

RLE

 8,134

FlateDecode

4/Indexed/DeviceRGB

2,832

图像文件总长度(字节)

946,600

PDF文件总长度(字节)

838,932

对比表3.1和表1.3,可以看看FreePic2Pdf优先考虑图像质料,其次考虑压缩比、生成速度。

另外用例1的首先张图纸很风趣,用libtiff带的TiffInfo查看它的音信如下:

TIFF Directory at offset 0xc3c6
Image Width: 1728 Image Length: 1103
Resolution: 204, 98 pixels/inch
Bits/Sample: 1
Compression Scheme: CCITT Group 3
Photometric Interpretation: min-is-white
FillOrder: lsb-to-msb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: (infinite)
Planar Configuration: single image plane
Page Number: 1-1
Software: fax2tiff
Group 3 Options: (0 = 0x0)
Fax Data: clean (0 = 0x0)
Bad Fax Lines: 0
Consecutive Bad Fax Lines: 0

那张图纸在大幅度方向上的扫视DPI约为长度方向的两倍(204/98),假使对那种差异处理不好,会带来意想不到的结果。以ACDSEE为例,5.0.1版展现该图片时就会变形,页面顶部的圆变成了扁椭圆,到8.0版时显得出了正圆,不过图像的长短从1103改为了2206,而且在ACDSEE
8打印和用PDF创制插件转换成PDF后,在PDF文件的图像大体表示中,那张图纸的尺寸均描述为2206象素。鲜明,ACDSEE内部对图像数据流举办了改动(沿长度方向放大一倍),以契合原长宽比,那对于图像显示软件以来无可厚非,可是对于PDF转换软件来说就有些多余,会增多最后PDF的文书长度。Image2Pdf没有对那张图纸的物理表示展开转移,而是准备通过调整图片的逻辑表示,由PDF
里德r在浮现时展开长宽比调整。但不幸的是,Image2Pdf
v1.7就好像把比例算反了,结果造成最终PDF突显出来后,圆变成了长椭圆。FreePic2Pdf吸取了那个教训,可以通过对图像逻辑表示的正确性安装,在不更改物理表示的情景下,
以正确的长宽比例展现该图像。

四、小结

  • 由于各类原因,近期图像转PDF工具不难并发图像数据流重新回落造成的题材读书的顺畅性问题对独特图像格式的支撑问题等。
  • 缓解图像数据流重新回落造成的题材的指出:对有损压缩的图像数据,应竭尽将原始数据流嵌入PDF文件,幸免重复回落造成图像质地衰减;对无损压缩图像数据,能够依照图像特点选取合适的无损压缩算法重新回落图像数据,以节约存储空间
    ,也可以直接将原始图像数据嵌入PDF,以节约重新回落所需的时间。
  • 解决阅读的顺畅性问题的提出:制作工具提供灵活多样的页面布局供用户按需选用,包含固定纸张大小、固定纸张宽度、按图像大小调整纸张大小等。页面大小的例外不应对本来图像数据流(图像的大体表示)造成影响,而是通过定义图像的逻辑表示,由PDF
    Reader本身来成功需要的图像缩放。
  • 对相当图像格式的支撑,需求针对具体意况举办付出。

为了声明自己提议的上述问题及其解决形式,我付出了一个免费的图像转PDF工具FreePic2Pdf,有亟待的可以到自家的网站下载。该软件考虑的预先顺序依次是:图像质料、PDF文件大小、转换速度。

五、题外话一:PDF转图像

眼前说了半天图像转PDF,自然会发生一个题目:将PDF转成图像又何以?

自我个人认为当前将PDF转成图像也得以分为二种:

  • 将PDF每一页的情节(包蕴图像和文字)转成一个图像文件,从感觉上看似于对PDF
    Reader的显示区举办截屏。
  • 从PDF文件里找出原来图像数据流,然后转存成对应的图像文件。

首先种的意味软件包蕴verypdf商家的PDF2HTML等。PDF2HTML除了将页面转成图像,仍可以生成包括图像和翻页按钮的HTML页面,方便在未曾设置PDF
里德r的机械上浏览原PDF文件的情节。可是在那种“眉毛胡子一把抓”的变换结果里要取出某幅图像的始末,差不离只可以用Photoshop逐步抠了。

第三种的象征软件包涵Adobe Acrobat
Professional(菜单项:Advanced->Export All
Images)。倘若喜欢开源代码,也可以看看Xpdf集体提供的pdfimages。从自家利用的结果看,Acrobat略显霸气,不管原来的图像是怎样格式,转换出来都成了一种格式。pdfimages稍好一点,JPG数据流
可以一直导出成JPG文件,其余无损数据流解码后导出为ppm文件,然而对于一些特殊色彩空间(ColorSpace)的JPG数据流,直接导出会促成偏色,只好解码后导出为ppm文件。
其实有的差异平常色彩空间可以导出为JPG压缩的TIFF文件,从而幸免对数码举办解码、再压缩,pdfimages不知底干什么从来不设想。

六、题外话二:除了PDF,还有哪些?

以IT界的观点来看,电子文档发展到前几天正史也不算短了,而且由于巨大市场前景的吸引,各厂家也都苦恼推出了上下一心的格式。单纯从以辅助扫描图像为主的电子文档来说,格式虽多,不过可以成气象、形成规范的,除了PDF格式外,还有多页TIFF、JBIG2、DjVu等。这个格式的共同点是:

  • 协理多页,可以将整卷档案或整部书存储在一个文书中。
  • 安分守己开放的专业,可以接收起先进的图像压缩技术为己用。

理所当然那一个格式近年来的影响力都不如PDF,我认为原因也都大致:

  • 宣传和商海工作做得不够。PDF在改为ISO标准前有Adobe公司在花大力气推动,现在更有N家集团卷了进入,市场的烧饼越做越大,相比之下别的格式就显得技术有余,市场供不应求。
  • 对应的支撑工具和软件不足。PDF虚拟打印机用起来多造福,其它格式的虚拟打印机则少得多。就到底用专用工具辛劳顿苦做出来,想和其外人享受收获的时候,还得问问他的机器上有没有装相应的浏览软件,未免太麻烦。当然浏览的问题和前一个题材相关,几年前也不是兼备机器上都装PDF
    里德r的。

1、多页TIFF

这一个应该算比较老的专业了,由于扫描、出版界传统上就习惯用TIFF格式,所以将多页TIFF作为电子文档的一种标准格式,应该是名正言顺的事,国内有的省市先行制定的电子档案管理相关规定也曾要求用多页TIFF作为扫描电子文件的仓储格式。

不过从骨子里情形看,真正用多页TIFF存储的电子文档并不多,在二〇〇五年揭橥执行的《中华夏族民共和国行业标准DA/T31—2005
纸质档案数字化技术标准》中,干脆就没多页TIFF什么事:

8图像存储
8·1存储格式
8·1·1应用黑白二值格局扫描的图像文件,一般接纳TIFF(G4)格式存储。选取灰度方式和彩色情势扫描的文件,一般选择JPEG格式存储。存储时的压缩率的接纳,应以保险扫描的图像清晰可读的前提下,尽量减小存储容量为轨道。
8·1·2提供网络查询的围观图像,也可存储为CEB、PDF或任何格式。

多页TIFF为啥会晤临冷落呢?我狐疑的来由不外乎:

  • 缺少有益的浏览工具。众所周知IE不支持TIFF格式,所以网上浏览TIFF只好依靠专门开发的控件。即便只在地方机上浏览,也唯有ACDSEE等为数不多的图像浏览软件辅助多页TIFF,浏览时想做标注、笔记很狼狈。
  • 格式不正规,那么些也许是无比致命的题材。从自己接触的气象看,由于历史的、技术的和其它的因由,方今国内广大扫描外包服务公司提供的扫视TIFF文件,
    黑白图像用G4减弱不会有怎么着问题,可是灰度、彩色图像在有损压缩时多半都用OJPEG压缩,而且格式多与正统不符,那就导致扫描出来的图像只可以用该公司提供的图像浏览软件才能浏览,极大地界定了TIFF文件的传入。俺在实质上工作中为了处理客户遍布全国的分支机构委托当地外包商扫描的档案文件,与那么些非标准TIFF文件举办了漫漫的、费劲卓越的奋斗(看看我的ComicEnhancer
    Pro近期的换代记录就知道了),
    相信有资格说这句话。我信任在《中中原人民共和国行业标准DA/T31—2005
    纸质档案数字化技术标准》中规定灰度和彩色图像用JPG存储,也就是为了防止生出这么些不专业的有损压缩TIFF文件。

不过对于TIFF格式的精力,我个人尚未表示猜忌:与某些静态图像格式不一致,TIFF标准平素在与时俱进,不断将先进的图像压缩技术吸收进去,如今曾经帮衬主流的CCITT、JPEG、LZW、ZIP等技能,新本子的草案中则陈设蕴涵对JPEG
2000、JBIG2等先进算法的支持。那一个都让我充满梦想。

2、JBIG2

这种格式专门针对以文字为主、黑白扫描的图像文件,属无损压缩,据称比G4压缩算法的压缩率高很多,近来已化作ISO标准,PDF从1.4版(Acrobat
5.0)开首容许内嵌JBIG2图像,未来的TIFF标准也打算接受JBIG2压缩算法。

JBIG2的法则类似OCR:先对图像举行划分、匹配,在辨明出子图像(如文字)后,将整幅图像看作子图像及其位置的集合,存储时只存储子图像和子图像出现的岗位,其他背景信息全部过滤掉,因而不但可以提供很高的压缩比,而且可以落成类似文字检索的图像全文检索。

尽管如从前景诱人,可是我个人认为JBIG2当下还存在下列问题:

  • 压缩率严重器重于图像本身的始末和削减引擎的模板表。对于字母文字来说,字母总数毕竟有限,由此重码率很高,自然裁减比也很高,不过对于华语来说,可能就没那样可以了。然而从自己试用的图景看,至少不会比CCITT
    G4的压缩比差。
  • 缺乏要求的代码襄助,严重阻碍了该标准的放大普及。与其它图像格式分裂,如今还尚无一个开源协会提供真正的JBIG2减小协助:Markus
    Kuhn
    提供的JBIG-KIT只支持JBIG1,并曾经终止更新;jbig2dec只提供解码代码(俺怀疑PDF的JBIG2解码代码就源于这里),不提供编码代码。

3、DjVu

其一也是针对性扫描电子文档的,但是与JBIG2不等,针对的是万紫千红、图文混排的图像。

DjVu的法则是先对图像实行分析,然后依据内容分层,包蕴背景层、文字层、图像层等,对两样的层使用不相同的压缩算法和参数,以获取最好的图像质料和压缩比。

与JBIG2不同,DjVu不仅有djvuzone组织在保安,而且有开源项目DjVuLibre作为协理,由此现在不唯有例外平台下的编码、解码器,连查看DjVu文件的IE插件都发布了,未来应有大有希望。

4、双层PDF

双层PDF是这么的PDF文件:PDF文件的每一页都包罗两层,下层是从纸质文件扫描出来的原本图像
,上层是用OCR软件对扫描图像举办辨认后发出的文字结果,但字体效果设置成透明。那样用户在阅读PDF文件时见到的是扫描图像,可以100%封存原有版面效果(包含公章、签名),在急需的时候,又可以经过
透明的文字新闻帮助选用、复制、检索等效果。

与一般PDF文件比较,双层PDF可以同时兼顾视觉效果和应用方便性,因而在境内办公、档案领域正在引起器重,我个人相信会有美好的“钱途”。

引人注目,双层PDF的内容搜索、内容复制与OCR识别结果有一贯的关联。先不说脚下国内OCR软件的识别率如何,最要害的某些是当下并未其他一个汉语OCR引擎是免费、开源的(英文的则有gocr等一批),所以双层PDF生成工具也都不是免费的,而是“面向公司市场”,我深信不疑穷困的个人用户在不犯法的意况下很难消受得起。

admin

网站地图xml地图