7.4 过滤器¶

Filters

7.4.1 概述¶

General

中文英文

流过滤器在7.3.8，“流对象”中介绍。读取流数据时的一个选项是使用过滤器对其进行解码，以产生原始的非编码数据。是否这样做以及使用哪个解码过滤器或过滤器组合，可以在流字典中指定。

EXAMPLE 1

如果流字典指定使用ASCIIHexDecode过滤器，读取该流中数据的应用应将该流中的ASCII十六进制编码数据转换为原始二进制数据。

符合规范的写入器可能会对流中的数据进行编码（例如，采样图像的数据）以压缩它或将其转换为可移植的ASCII表示（或两者兼有）。符合规范的阅读器应调用相应的解码过滤器或过滤器，将信息转换回其原始形式。

流的过滤器或过滤器应由流字典中的Filter条目（如果流是外部的，则为FFilter条目）指定。过滤器可以级联形成管道，使流通过两个或更多连续的解码转换。例如，使用LZW和ASCII base-85编码（按该顺序）编码的数据应使用流字典中的以下条目进行解码：

EXAMPLE 2

/Filter [ /ASCII85Decode /LZWDecode ]

一些过滤器可能需要参数来控制它们的操作方式。这些可选参数应由流字典中的DecodeParms条目（如果流是外部的，则为FDecodeParms条目）指定。

PDF支持一组标准过滤器，它们分为两个主要类别：

ASCII过滤器(ASCII filters)允许解码已作为ASCII文本编码的任意二进制数据（见7.2，“词汇约定”，了解这种类型的编码可能有用的解释）。
解压缩过滤器(Decompression filters)允许解码已压缩的数据。压缩数据应为二进制格式，即使原始数据是ASCII文本。

NOTE 1

ASCII过滤器在加密的PDF文件中没有实际用途；见7.6，“加密”。

NOTE 2

压缩对于大型采样图像特别有价值，因为它减少了存储需求和传输时间。一些类型的压缩是有损的，意味着在编码过程中丢失了一些数据，导致数据解压缩时质量下降。不丢失数据的压缩称为无损压缩。虽然有些显而易见，但值得指出的是，有损压缩只能应用于采样图像数据（并且只有某些类型的有损压缩适用于某些类型的图像）。另一方面，无损压缩可以用于任何类型的流。

标准过滤器在表6中总结，这也表明它们是否接受任何可选参数。以下子条款更详细地描述了这些过滤器及其参数（如果有），包括一些过滤器的编码算法规范。

Table 6 – 标准过滤器
过滤器名称	参数	描述
ASCIIHexDecode	no	对使用ASCII十六进制表示编码的数据进行解码，还原原始二进制数据。
ASCII85Decode	no	对使用ASCII base-85表示编码的数据进行解码，还原原始二进制数据。
LZWDecode	yes	使用LZW（Lempel-Ziv-Welch）自适应压缩方法对编码的数据进行解压缩，还原原始文本或二进制数据。
FlateDecode	yes	(PDF 1.2) 使用zlib/deflate压缩方法对编码的数据进行解压缩，还原原始文本或二进制数据。
RunLengthDecode	no	使用面向字节的行程长度编码算法对编码的数据进行解压缩，还原原始文本或二进制数据（通常为单色图像数据，或包含单一字节值频繁长行程的任何数据）。
CCITTFaxDecode	yes	使用CCITT传真标准对编码的数据进行解压缩，还原原始数据（通常为每个像素1位的单色图像数据）。
JBIG2Decode	yes	(PDF 1.4) 使用JBIG2标准对编码的数据进行解压缩，还原原始单色（每个像素1位）图像数据（或该数据的近似值）。
DCTDecode	yes	使用基于JPEG标准的DCT（离散余弦变换）技术对编码的数据进行解压缩，还原近似原始数据的图像样本数据。
JPXDecode	no	(PDF 1.5) 使用基于小波的JPEG2000标准对编码的数据进行解压缩，还原原始图像数据。
Crypt	yes	(PDF 1.5) 由安全处理器加密的数据进行解密，还原为加密前的数据。

EXAMPLE 3

下面的示例展示了一个流，其中包含了页面的标记指令，该流首先使用LZW压缩方法进行压缩，然后使用ASCII base-85表示法进行编码。

1 0 obj
    << /Length 534
       /Filter [ /ASCII85Decode /LZWDecode ]
    >>
stream
J..)6T`?p&<!J9%_[umg"B7/Z7KNXbN'S+,*Q/&"OLT'F
LIDK#!n`$"<Atdi`\Vn%b%)&'cA*VnK\CJY(sF>c!Jnl@
RM]WM;jjH6Gnc75idkL5]+cPZKEBPWdR>FF(kj1_R%W_d
&/jS!;iuad7h?[L-F$+]]0A3Ck*$I0KZ?;<)CJtqi65Xb
Vc3\n5ua:Q/=0$W<#N3U;H,MQKqfg1?:lUpR;6oN[C2E4
ZNr8Udn.'p+?#X+1>0Kuk$bCDF/(3fL5]Oq)^kJZ!C2H1
'TO]Rl?Q:&'<5&iP!$Rq;BXRecDN[IJB`,)o8XJOSJ9sD
S]hQ;Rj@!ND)bD_q&C\g:inYC%)&u#:u,M6Bm%IY!Kb1+
":aAa'S`ViJglLb8<W9k6Yl\\0McJQkDeLWdPN?9A'jX*
al>iG1p&i;eVoK&juJHs9%;Xomop"5KatWRT"JQ#qYuL,
JD?M$0QP)lKn06l1apKDC@\qJ4B!!(5m+j.7F790m(Vj8
8l8Q:_CZ(Gm1%X\N1&u!FKHMB~>
endstream
endobj

kimi示例:

12 0 obj
<< /Filter [ /ASCII85Decode /LZWDecode ]
   /DecodeParms [
     << /ASCII85Decode << /DecodeParm1 ... >> 
     /LZWDecode
     << /LZWDecode <<
       /EarlyChange  true
       /Predictor    12
     >> ]
   ]
>>
stream
... ASCII base-85 编码的压缩数据 ...
endstream

在这个例子中，流对象通过其字典中的 /Filter 条目指定了两种过滤器：/ASCII85Decode 和 /LZWDecode。/DecodeParms 条目包含了每个过滤器的参数字典。对于 LZW 解码，可能包括参数如 EarlyChange 和 Predictor，这些参数控制解码的行为。流数据本身是使用这两种方法编码的，并且存储在 stream 和 endstream 关键字之间。

EXAMPLE 4

以下是提供的示例展示了一个没有应用任何过滤器的流（流的内容在7.8.2，“内容流”中有解释，那里使用的运算符在第9条款，“文本”中有更详细的描述）：

1 0 obj
    << /Length 568 >>
stream
2 J
BT
/F1 12 Tf
0 Tc
0 Tw
72.5 712 TD
[ ( 未过滤的流可以容易地被读取 ) 65 ( , ) ] TJ
0 -14 TD
[ ( b ) 20 ( ut 通常需要更多的空间 ) 10 ( e ) 20 ( 比压缩过的流 ) ] TJ
T* ( . ) Tj
0 -28 TD
[ ( Se ) 25 ( v ) 15 ( eral encoding methods are a ) 20 ( v) 25 ( ailable in PDF ) 80 ( . ) ] TJ
0 -14 TD
( 有些用于压缩，其他的只是 ) Tj
T* [ ( 用于以ASCII格式表示二进制数据。 ) ] TJ
T* ( 有些压缩过滤器适用于数据和图像， ) Tj
T* ( 而其他的仅适用于连续色调图像。 ) Tj
ET
endstream
endobj

译注:

请注意，这个示例中的文本是一个直接的翻译，并且保留了原文中的PDF内容流语法和操作符。在实际的PDF文件中，这些操作符将控制文本的显示方式，例如字体大小、位置和格式。

Stream filters are introduced in 7.3.8, "Stream Objects." An option when reading stream data is to decode it using a filter to produce the original non-encoded data. Whether to do so and which decoding filter or filters to use may be specified in the stream dictionary.

EXAMPLE 1

If a stream dictionary specifies the use of an ASCIIHexDecode filter, an application reading the data in that stream should transform the ASCII hexadecimal-encoded data in that stream in order to obtain the original binary data.

A conforming writer may encode data in a stream (for example, data for sampled images) to compress it or to convert it to a portable ASCII representation (or both). A conforming reader shall invoke the corresponding decoding filter or filters to convert the information back to its original form.

The filter or filters for a stream shall be specified by the Filter entry in the stream’s dictionary (or the FFilter entry if the stream is external). Filters may be cascaded to form a pipeline that passes the stream through two or more decoding transformations in sequence. For example, data encoded using LZW and ASCII base-85 encoding (in that order) shall be decoded using the following entry in the stream dictionary:

EXAMPLE 2

/Filter [ /ASCII85Decode /LZWDecode ]

Some filters may take parameters to control how they operate. These optional parameters shall be specified by the DecodeParms entry in the stream’s dictionary (or the FDecodeParms entry if the stream is external).

PDF supports a standard set of filters that fall into two main categories:

ASCII filters enable decoding of arbitrary binary data that has been encoded as ASCII text (see 7.2, "Lexical Conventions," for an explanation of why this type of encoding might be useful).
Decompression filters enable decoding of data that has been compressed. The compressed data shall be in binary format, even if the original data is ASCII text.

NOTE 1

ASCII filters serve no useful purpose in a PDF file that is encrypted; see 7.6, “Encryption”.

NOTE 2

Compression is particularly valuable for large sampled images, since it reduces storage requirements and transmission time. Some types of compression are lossy, meaning that some data is lost during the encoding, resulting in a loss of quality when the data is decompressed. Compression in which no loss of data occurs is called lossless. Though somehow obvious it might be worth pointing out that lossy compression can only be applied to sampled image data (and only certain types of lossy compression for certain types of images). Lossless compression on the other hand can be used for any kind of stream.

The standard filters are summarized in Table 6, which also indicates whether they accept any optiona parameters. The following sub-clauses describe these filters and their parameters (if any) in greater detail including specifications of encoding algorithms for some filters.

Table 6 – Standard filters
FILTER name	Parameters	Description
ASCIIHexDecode	no	Decodes data encoded in an ASCII hexadecimal representation, reproducing the original binary data.
ASCII85Decode	no	Decodes data encoded in an ASCII base-85 representation, reproducing the original binary data.
LZWDecode	yes	Decompresses data encoded using the LZW (Lempel-Ziv-Welch) adaptive compression method, reproducing the original text or binary data.
FlateDecode	yes	(PDF 1.2) Decompresses data encoded using the zlib/deflate compression method, reproducing the original text or binary data.
RunLengthDecode	no	Decompresses data encoded using a byte-oriented run-length encoding algorithm, reproducing the original text or binary data (typically monochrome image data, or any data that contains frequent long runs of a single byte value).
CCITTFaxDecode	yes	Decompresses data encoded using the CCITT facsimile standard, reproducing the original data (typically monochrome image data at 1 bit per pixel).
JBIG2Decode	yes	(PDF 1.4) Decompresses data encoded using the JBIG2 standard, reproducing the original monochrome (1 bit per pixel) image data (or an approximation of that data).
DCTDecode	yes	Decompresses data encoded using a DCT (discrete cosine transform) technique based on the JPEG standard, reproducing image sample data that approximates the original data.
JPXDecode	no	(PDF 1.5) Decompresses data encoded using the wavelet-based JPEG2000 standard, reproducing the original image data.
Crypt	yes	(PDF 1.5) Decrypts data encrypted by a security handler, reproducing the data as it was before encryption.

EXAMPLE 3

The following example shows a stream, containing the marking instructions for a page, that was compressed using the LZW compression method and then encoded in ASCII base-85 representation.

1 0 obj
    << /Length 534
       /Filter [ /ASCII85Decode /LZWDecode ]
    >>
stream
J..)6T`?p&<!J9%_[umg"B7/Z7KNXbN'S+,*Q/&"OLT'F
LIDK#!n`$"<Atdi`\Vn%b%)&'cA*VnK\CJY(sF>c!Jnl@
RM]WM;jjH6Gnc75idkL5]+cPZKEBPWdR>FF(kj1_R%W_d
&/jS!;iuad7h?[L-F$+]]0A3Ck*$I0KZ?;<)CJtqi65Xb
Vc3\n5ua:Q/=0$W<#N3U;H,MQKqfg1?:lUpR;6oN[C2E4
ZNr8Udn.'p+?#X+1>0Kuk$bCDF/(3fL5]Oq)^kJZ!C2H1
'TO]Rl?Q:&'<5&iP!$Rq;BXRecDN[IJB`,)o8XJOSJ9sD
S]hQ;Rj@!ND)bD_q&C\g:inYC%)&u#:u,M6Bm%IY!Kb1+
":aAa'S`ViJglLb8<W9k6Yl\\0McJQkDeLWdPN?9A'jX*
al>iG1p&i;eVoK&juJHs9%;Xomop"5KatWRT"JQ#qYuL,
JD?M$0QP)lKn06l1apKDC@\qJ4B!!(5m+j.7F790m(Vj8
8l8Q:_CZ(Gm1%X\N1&u!FKHMB~>
endstream
endobj

EXAMPLE 4

The following shows the same stream without any filters applied to it. (The stream’s contents are explained in 7.8.2, "Content Streams," and the operators used there are further described in clause 9, "Text".)

1 0 obj
    << /Length 568 >>
stream
2 J
BT
/F1 12 Tf
0 Tc
0 Tw
72.5 712 TD
[ ( Unfiltered streams can be read easily ) 65 ( , ) ] TJ
0 -14 TD
[ ( b ) 20 ( ut generally tak ) 10 ( e more space than \311 ) ] TJ
T* ( compressed streams . ) Tj
0 -28 TD
[ ( Se ) 25 ( v ) 15 ( eral encoding methods are a ) 20 ( v) 25 ( ailable in PDF ) 80 ( . ) ] TJ
0 -14 TD
( Some are used for compression and others simply ) Tj
T* [ ( to represent binary data in an ) 55 ( ASCII format . ) ] TJ
T* ( Some of the compression filters are \
suitable ) Tj
T* ( for both data and images , while others are \
suitable only ) Tj
T* ( for continuous-tone images . ) Tj
ET
endstream
endobj

7.4.2 ASCIIHexDecode 过滤器¶

ASCIIHexDecode Filter

中文英文

ASCIIHexDecode 过滤器对已用 ASCII 十六进制形式编码的数据进行解码。ASCII 十六进制编码和 ASCII base-85 编码（见7.4.3，“ASCII85Decode 过滤器”）将二进制数据（如图像数据或之前压缩过的数据）转换为 7 位 ASCII 字符。

NOTE

倾向于使用 ASCII base-85 编码而不是 ASCII 十六进制编码。之所以偏好 base-85 编码，是因为它更紧凑：它以 4:5 的比例扩展数据，而 ASCII 十六进制编码则为 1:2。

ASCIIHexDecode 过滤器应对每对 ASCII 十六进制数字（0-9 和 A-F 或 a-f）生成一个字节的二进制数据。应忽略所有空白字符（见7.2，“词汇约定”）。大于号（3Eh）表示文件结束（EOD）。遇到任何其他字符都应导致错误。如果过滤器在读取奇数个十六进制数字后遇到 EOD 标记，它应表现得就像最后一个数字后面跟了一个 0（零）。

The ASCIIHexDecode filter decodes data that has been encoded in ASCII hexadecimal form. ASCII hexadecimal encoding and ASCII base-85 encoding (7.4.3, "ASCII85Decode Filter") convert binary data, such as image data or previously compressed data, to 7-bit ASCII characters.

NOTE

ASCII base-85 encoding is preferred to ASCII hexadecimal encoding. Base-85 encoding is preferred because it is more compact: it expands the data by a factor of 4 : 5, compared with 1 : 2 for ASCII hexadecimal encoding.

The ASCIIHexDecode filter shall produce one byte of binary data for each pair of ASCII hexadecimal digits (0–9 and A–F or a–f). All white-space characters (see 7.2, "Lexical Conventions") shall be ignored. A GREATER-THAN SIGN (3Eh) indicates EOD. Any other characters shall cause an error. If the filter encounters the EOD marker after reading an odd number of hexadecimal digits, it shall behave as if a 0 (zero) followed the last digit.

7.4.3 ASCII85Decode 过滤器¶

ASCII85Decode Filter

中文英文

ASCII85Decode 过滤器对使用 ASCII base-85 编码编码的数据进行解码，并产生二进制数据。以下段落描述了用 ASCII base-85 对二进制数据进行编码的过程；ASCII85Decode 过滤器则逆转这一过程。

ASCII base-85 编码应使用 ASCII 字符 ! 到 u (21h - 75h) 和字符 z (7Ah)，用两个字符序列 ~> (7Eh)(3Eh) 作为其文件结束（EOD）标记。ASCII85Decode 过滤器应忽略所有空白字符（见7.2，“词汇约定”）。任何其他字符，以及在 ASCII base-85 编码中代表不可能组合的任何字符序列，都应导致错误。

具体来说，ASCII base-85 编码应对每 4 个字节的二进制数据产生 5 个 ASCII 字符。每组 4 个字节的输入，(\(b_1\) \(b_2\) \(b_3\) \(b_4\) )，应使用以下关系转换为一组 5 个字节的输出，(\(c_1\) \(c_2\) \(c_3\) \(c_4\) \(c_5\) )：

\(\((b_1 \times 256^3)+(b_2 \times 256^2 ) + (b_3 \times 256 ^ 1) = \newline (c_1 \times 85^4)+(c_2 \times 85^3) + (c_3 \times 85^2)+(c_4 \times 85^1)\)\)

换句话说，4 个字节的二进制数据应被解释为一个基于 256 的数字，然后转换为一个基于 85 的数字。基于 85 的数字的五个字节随后应通过每个数字加 33（字符 ! 的 ASCII 码）转换为 ASCII 字符。得到的编码数据应只包含可打印的 ASCII 字符，其代码范围在 33 (!) 到 117 (u) 之间。作为一个特殊情况，如果所有五个字节都是 0，它们应由代码 122 (z) 的字符代替五个感叹号 (!!!!!)。

如果待编码数据的长度不是 4 个字节的倍数，最后的、部分的 4 字节组将被用来产生最后的部分的 5 个输出字符。给定 n (1, 2, 或 3) 个字节的二进制数据，编码器首先添加 4 - n 个零字节以构成一个完整的 4 字节组。它应按通常的方式对这组数据进行编码，但不应应用特殊的 z 情况。最后，它应只写出所得 5 字节组中的前 n + 1 个字符。这些字符应立即跟随 ~> EOD 标记。

以下条件在正确编码的字节序列中决不应出现：

由 5 个字符组表示的值大于 \(2^32 - 1\)。
z 字符出现在组的中间。
最后的局部组只包含一个字符。

The ASCII85Decode filter decodes data that has been encoded in ASCII base-85 encoding and produces binary data. The following paragraphs describe the process for encoding binary data in ASCII base-85; the ASCII85Decode filter reverses this process.

The ASCII base-85 encoding shall use the ASCII characters ! through u ((21h) - (75h)) and the character z (7Ah), with the 2-character sequence ~> (7Eh)(3Eh) as its EOD marker. The ASCII85Decode filter shall ignore all white-space characters (see 7.2, "Lexical Conventions"). Any other characters, and any character sequences that represent impossible combinations in the ASCII base-85 encoding shall cause an error.

Specifically, ASCII base-85 encoding shall produce 5 ASCII characters for every 4 bytes of binary data. Each group of 4 binary input bytes, (\(b_1\) \(b_2\) \(b_3\) \(b_4\) ), shall be converted to a group of 5 output bytes, (\(c_1\) \(c_2\) \(c_3\) \(c_4\) \(c_5\) ), using the relation

\[(b_1 \times 256^3)+(b_2 \times 256^2 ) + (b_3 \times 256 ^ 1) = \newline (c_1 \times 85^4)+(c_2 \times 85^3) + (c_3 \times 85^2)+(c_4 \times 85^1)\]

In other words, 4 bytes of binary data shall be interpreted as a base-256 number and then shall be converted to a base-85 number. The five bytes of the base-85 number shall then be converted to ASCII characters by adding 33 (the ASCII code for the character ! ) to each. The resulting encoded data shall contain only printable ASCII characters with codes in the range 33 (!) to 117 (u). As a special case, if all five bytes are 0, they shall be represented by the character with code 122 (z) instead of by five exclamation points ( ! ! ! ! ! ).

If the length of the data to be encoded is not a multiple of 4 bytes, the last, partial group of 4 shall be used to produce a last, partial group of 5 output characters. Given n (1, 2, or 3) bytes of binary data, the encoder shall first append 4 - n zero bytes to make a complete group of 4. It shall encode this group in the usual way, but shall not apply the special z case. Finally, it shall write only the first n + 1 characters of the resulting group of 5. These characters shall be immediately followed by the ~> EOD marker.

The following conditions shall never occur in a correctly encoded byte sequence:

The value represented by a group of 5 characters is greater than \(2^32 - 1\).
A z character occurs in the middle of a group.
A final partial group contains only one character.

7.4.4 LZWDecode 和 FlateDecode 过滤器¶

LZWDecode and FlateDecode Filters

7.4.4.1 概述¶

General

中文英文

LZWDecode 和 (PDF 1.2) FlateDecode 过滤器有很多共同点，在本子条款中一起讨论。它们分别对使用 LZW 或 Flate 数据压缩方法编码的数据进行解码：

LZW（Lempel-Ziv-Welch）是一种可变长度的自适应压缩方法，已被采纳为 标签图像文件格式（TIFF）标准中的一种标准压缩方法。有关 LZW 编码的详细信息，见7.4.4.2，“LZW 编码细节”。
Flate 方法基于公共领域的 zlib/deflate 压缩方法，这是一种可变长度的 Lempel-Ziv 自适应压缩方法，与自适应 Huffman 编码级联。它在互联网 RFCs 1950, ZLIB 压缩数据格式规范，和 1951, DEFLATE 压缩数据格式规范中有完整定义（见参考文献）。

这两种方法都可以压缩二进制数据或 ASCII 文本，但（像所有压缩方法一样）始终产生二进制数据，即使原始数据是文本。

LZW 和 Flate 压缩方法可以发现并利用输入数据中的许多模式，无论是文本还是图像数据。如后文所述，两种过滤器都支持可选的预测函数转换，这提高了采样图像数据的压缩效果。

NOTE 1

由于其级联的自适应 Huffman 编码，Flate 编码的输出通常比相同输入的 LZW 编码的输出要紧凑得多。Flate 和 LZW 解码速度相当，但 Flate 编码比 LZW 编码慢得多。

NOTE 2

通常，Flate 和 LZW 编码都会大大压缩其输入。然而，在最坏的情况下（没有一对相邻的字节出现两次），Flate 编码将其输入扩大不超过 11 个字节或 1.003 倍（以较大者为准），加上 PNG 预测器添加的算法标签的影响。对于 LZW 编码，最佳情况（全部为零）为长文件提供了接近 1365:1 的压缩比，但最坏情况的扩展至少为 1.125 倍，这在某些实现中可能增加到近 1.5 倍，加上与 Flate 编码相同的 PNG 标签的影响。

The LZWDecode and (PDF 1.2) FlateDecode filters have much in common and are discussed together in this sub-clause. They decode data that has been encoded using the LZW or Flate data compression method, respectively:

LZW (Lempel-Ziv-Welch) is a variable-length, adaptive compression method that has been adopted as one of the standard compression methods in the Tag Image File Format (TIFF) standard. For details on LZW encoding see 7.4.4.2, "Details of LZW Encoding."
The Flate method is based on the public-domain zlib/deflate compression method, which is a variable-length Lempel-Ziv adaptive compression method cascaded with adaptive Huffman coding. It is fully defined in Internet RFCs 1950, ZLIB Compressed Data Format Specification, and 1951, DEFLATE Compressed Data Format Specification (see the Bibliography).

Both of these methods compress either binary data or ASCII text but (like all compression methods) always produce binary data, even if the original data was text.

The LZW and Flate compression methods can discover and exploit many patterns in the input data, whether the data is text or images. As described later, both filters support optional transformation by a predictor function, which improves the compression of sampled image data.

NOTE 1

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

NOTE 2

Usually, both Flate and LZW encodings compress their input substantially. However, in the worst case (in which no pair of adjacent bytes appears twice), Flate encoding expands its input by no more than 11 bytes or a factor of 1.003 (whichever is larger), plus the effects of algorithm tags added by PNG predictors. For LZW encoding, the best case (all zeros) provides a compression approaching 1365 : 1 for long files, but the worst- case expansion is at least a factor of 1.125, which can increase to nearly 1.5 in some implementations, plus the effects of PNG tags as with Flate encoding.

7.4.4.2 LZW编码细节¶

Details of LZW Encoding

中文英文

使用LZW压缩方法编码的数据应由一系列9到12位长的代码组成。每个代码应表示一个输入数据的单个字符（0-255）、清空表标记（256）、文件结束（EOD）标记（257），或者表示在输入中先前遇到的多字符序列的表条目（258或更大）。

最初，代码长度为9位，LZW表仅包含用于258个固定代码的条目。随着编码的进行，将向表中添加条目，将新代码与越来越长的输入字符序列关联起来。编码器和解码器应维护这个表的相同副本。

每当编码器和解码器独立地（但同步地）意识到当前代码长度不再足以表示表中的条目数时，它们应将每个代码的位数增加1。第一个输出代码为10位长的是创建表条目511之后的那个，类似地，对于11位（1023）和12位（2047）。代码永远不会超过12位长；因此，条目4095是LZW表的最后一个条目。

编码器应执行以下步骤序列以生成每个输出代码：

a) 累积一个或多个已存在于表中的输入字符序列。为了获得最大压缩效果，编码器寻找最长的此类序列。

b) 发出与该序列对应的代码。

c) 为第一个未使用的代码创建一个新的表条目。它的值是步骤(a)中找到的序列，后面跟着下一个输入字符。

EXAMPLE 1

假设输入由以下ASCII字符代码序列组成：

45 45 45 45 45 65 45 45 45 66

从空表开始，编码器的步骤如表7所示。

Table 7 – 典型的LZW编码序列
输入序列	输出代码	添加到表中的代码	新代码表示的序列
--	256 (clear-table)	--	--
45	45	258	45 45
45 45	258	259	45 45 45
45 45	258	260	45 45 65
65	65	261	65 45
45 45 45	259	262	45 45 45 66
66	66	--	--
--	257 (EOD)	--	--

代码应被打包成一个连续的比特流，高位比特在前。然后这个流应被划分为字节，同样高位比特在前。因此，代码可以任意跨越字节边界。在EOD标记（代码值257）之后，最终字节中剩余的比特应设为0。

在上述示例中，所有的输出代码都是9位长；它们将被打包为字节，如下所示（以十六进制表示）：

EXAMPLE 2

80 0B 60 50 22 0C 0C 85 01

为了适应变化的输入序列，编码器可以在任何时候发出清空表代码，这会导致编码器和解码器都重新使用初始表和9位代码长度开始。编码器应首先发出清空表代码。当表满时，它应发出清空表代码；它可能更早这样做。

Data encoded using the LZW compression method shall consist of a sequence of codes that are 9 to 12 bits long. Each code shall represent a single character of input data (0–255), a clear-table marker (256), an EOD marker (257), or a table entry representing a multiple-character sequence that has been encountered previously in the input (258 or greater).

Initially, the code length shall be 9 bits and the LZW table shall contain only entries for the 258 fixed codes. As encoding proceeds, entries shall be appended to the table, associating new codes with longer and longer sequences of input characters. The encoder and the decoder shall maintain identical copies of this table.

Whenever both the encoder and the decoder independently (but synchronously) realize that the current code length is no longer sufficient to represent the number of entries in the table, they shall increase the number of bits per code by 1. The first output code that is 10 bits long shall be the one following the creation of table entry 511, and similarly for 11 (1023) and 12 (2047) bits. Codes shall never be longer than 12 bits; therefore, entry 4095 is the last entry of the LZW table.

The encoder shall execute the following sequence of steps to generate each output code:

a) Accumulate a sequence of one or more input characters matching a sequence already present in the table. For maximum compression, the encoder looks for the longest such sequence.

b) Emit the code corresponding to that sequence.

c) Create a new table entry for the first unused code. Its value is the sequence found in step (a) followed by the next input character.

EXAMPLE 1

Suppose the input consists of the following sequence of ASCII character codes:

45 45 45 45 45 65 45 45 45 66

Starting with an empty table, the encoder proceeds as shown in Table 7.

Table 7 – Typical LZW encoding sequence
Input sequence	Output code	Code added to table	Sequence represented by new code
--	256 (clear-table)	--	--
45	45	258	45 45
45 45	258	259	45 45 45
45 45	258	260	45 45 65
65	65	261	65 45
45 45 45	259	262	45 45 45 66
66	66	--	--
--	257 (EOD)	--	--

Codes shall be packed into a continuous bit stream, high-order bit first. This stream shall then be divided into bytes, high-order bit first. Thus, codes may straddle byte boundaries arbitrarily. After the EOD marker (code value 257), any leftover bits in the final byte shall be set to 0.

In the example above, all the output codes are 9 bits long; they would pack into bytes as follows (represented in hexadecimal):

EXAMPLE 2

80 0B 60 50 22 0C 0C 85 01

To adapt to changing input sequences, the encoder may at any point issue a clear-table code, which causes both the encoder and the decoder to restart with initial tables and a 9-bit code length. The encoder shall begin by issuing a clear-table code. It shall issue a clear-table code when the table becomes full; it may do so sooner.

7.4.4.3 LZWDecode 和 FlateDecode 参数¶

LZWDecode and FlateDecode Parameters

中文英文

LZWDecode 和 FlateDecode 过滤器将接受可选参数以控制解码过程。

NOTE

这些参数大多与减少压缩采样图像大小的技术有关（矩形阵列的颜色值，见8.9，“图像”）。例如，图像数据通常从样本到样本变化很小。因此，对相邻样本的值进行减法（称为差分的过程），并编码差异而不是原始样本值，可以减少输出数据的大小。此外，当图像数据包含每个样本的几个颜色分量（红-绿-蓝或青-品红-黄-黑）时，取相邻样本中相应分量的差值，而不是同一样本中不同颜色分量的差值，通常可以减少输出数据的大小。

表8显示了可能为 LZWDecode 和 FlateDecode 过滤器指定的可选参数。除非另有说明，所有提供给解码过滤器的任何可选参数的值应与编码数据时使用的值相匹配。

Table 8 – LZWDecode 和 FlateDecode 过滤器的可选参数
Key	Type	Value
Predictor	integer	选择预测算法的代码（如果有）。如果此条目的值为1，则过滤器应假定在编码数据时使用了正常算法，没有预测。如果该值大于1，则过滤器应假定数据在编码之前已差分，并由 Predictor 选择预测算法。有关 Predictor 值大于1的更多信息，见7.4.4.4，“LZW 和 Flate 预测函数”。默认值：1。
Colors	integer	(只能在 Predictor 大于1时使用) 每个样本中交错的颜色分量的数量。有效值为1到4（PDF 1.0）和1或更大（PDF 1.3）。默认值：1。
BitsPerComponent	yes	(只能在 Predictor 大于1时使用) 每个颜色分量的位数。有效值是1, 2, 4, 8, 和 (PDF 1.5) 16。默认值：8。
FlateDecode	integer	(只能在 Predictor 大于1时使用) 每个样本中用于表示颜色分量的位数。有效值为 1、2、4、8，以及 (PDF 1.5) 16。默认值：8。
Columns	integer	(只能在 Predictor 大于1时使用) 每行的样本数。默认值：1。
EarlyChange	integer	(LZWDecode 专用) 指示何时增加代码长度。如果此条目的值为0，则尽可能推迟代码长度增加。如果该值为1，则提前一个代码进行代码长度增加。这个参数被包括在内是因为一些供应商分发的LZW样本代码比必要时更早地增加了代码长度。默认值：1。

The LZWDecode and FlateDecode filters shall accept optional parameters to control the decoding process.

NOTE

Most of these parameters are related to techniques that reduce the size of compressed sampled images (rectangular arrays of colour values, described in 8.9, "Images"). For example, image data typically changes very little from sample to sample. Therefore, subtracting the values of adjacent samples (a process called differencing), and encoding the differences rather than the raw sample values, can reduce the size of the output data. Furthermore, when the image data contains several colour components (red-green-blue or cyan- magenta-yellow-black) per sample, taking the difference between the values of corresponding components in adjacent samples, rather than between different colour components in the same sample, often reduces the output data size.

Table 8 shows the parameters that may optionally be specified for LZWDecode and FlateDecode filters. Except where otherwise noted, all values supplied to the decoding filter for any optional parameters shall match those used when the data was encoded.

Table 8 – Optional parameters for LZWDecode and FlateDecode filters
Key	Type	Value
Predictor	integer	A code that selects the predictor algorithm, if any. If the value of this entry is 1, the filter shall assume that the normal algorithm was used to encode the data, without prediction. If the value is greater than 1, the filter shall assume that the data was differenced before being encoded, and Predictor selects the predictor algorithm. For more information regarding Predictor values greater than 1, see 7.4.4.4, "LZW and Flate Predictor Functions." Default value: 1.
Colors	integer	(May be used only if Predictor is greater than 1) The number of interleaved colour components per sample. Valid values are 1 to 4 (PDF 1.0) and 1 or greater (PDF 1.3). Default value: 1.
BitsPerComponent	yes	Decompresses data encoded using the LZW (Lempel-Ziv-Welch) adaptive compression method, reproducing the original text or binary data.
FlateDecode	integer	(May be used only if Predictor is greater than 1) The number of bits used to represent each colour component in a sample. Valid values are 1, 2, 4, 8, and (PDF 1.5) 16. Default value: 8.
Columns	integer	(May be used only if Predictor is greater than 1) The number of samples in each row. Default value: 1.
EarlyChange	integer	(LZWDecode only) An indication of when to increase the code length. If the value of this entry is 0, code length increases shall be postponed as long as possible. If the value is 1, code length increases shall occur one code early. This parameter is included because LZW sample code distributed by some vendors increases the code length one code earlier than necessary. Default value: 1.

7.4.4.4 LZW 和 Flate 预测函数¶

LZW and Flate Predictor Functions

中文英文

LZW 和 Flate 编码如果输入数据具有高度可预测性，则可以更有效地压缩。提高许多连续色调采样图像可预测性的一个方法是将每个样本替换为该样本与应用于早期邻近样本的预测函数之间的差值。如果预测函数运作良好，预测后的数据会趋向于 0。

PDF 支持两组预测函数。第一组，TIFF 组，只包含 TIFF 6.0 规范中的 Predictor 2 这一个函数。

NOTE 1

（在 TIFF 6.0 规范中，Predictor 2 仅适用于 LZW 压缩，但在这里它也适用于 Flate 压缩。）TIFF Predictor 2 预测每个样本的颜色分量与紧邻其左侧样本的相应颜色分量相同。

第二组支持的预测函数是 PNG 组，由万维网联盟的便携式网络图形推荐使用的过滤器组成，记录在互联网 RFC 2083，PNG（便携式网络图形）规范中（见参考文献）。

为了避免混淆，这里使用“预测函数”一词而不是“过滤器”。

有五种基本的 PNG 预测算法（还有一个选择每个行分别选择最优预测函数的第六种算法）。

Table 9 – PNG 预测算法
PNG 预测算法	描述
None	无预测
Sub	预测与左侧样本相同
Up	预测与上方样本相同
Average	预测左上方样本和上方样本的平均值
Paeth	上方样本、左侧样本和左上角样本的非线性函数

要使用的预测算法（如果有）应由 Predictor 过滤器参数指示（见表8），其值应为表10 中列出的值之一。

对于 LZWDecode 和 FlateDecode，Predictor 值大于或等于 10 应表示正在使用 PNG 预测器；所使用的特定预测函数应明确编码在传入数据中。如果编码过滤器和解码过滤器提供的 Predictor 值都大于或等于 10，则它们不必匹配。

Table 10 – 预测函数值
值	意义
1	无预测（默认值）
2	TIFF 预测 2
10	PNG 预测 (编码时，所有行使用 PNG None)
11	PNG 预测 (编码时，所有行使用 PNG Sub)
12	PNG 预测 (编码时，所有行使用 PNG Up)
13	PNG 预测 (编码时，所有行使用 PNG Average)
14	PNG 预测 (编码时，所有行使用 PNG Paeth)
15	PNG 预测 (编码时，PNG 最优选择)

这两组预测函数有一些共同点。两者都做出以下假设：

数据应按顺序呈现，从顶行到底层行，并且在一行内，从左到右。
一行应占用整数个字节，如果需要，向上取整。
样本及其分量应从高阶到低阶比特打包成字节。
图像外的所有颜色分量的样本（对于边界附近的预测是必要的）应为0。

预测函数组在重要方面也有所不同：

每行使用PNG预测的数据后的预测数据应以显式的算法标签开始；因此，不同的行可以使用不同的算法进行预测以提高压缩效果。TIFF Predictor 2没有这样的标识符；相同的算法适用于所有行。
TIFF函数组应预测每个颜色分量，从前一个实例开始，考虑到每个分量的位数和每个样本的分量数。相比之下，PNG函数组应预测每个字节的数据，作为一个字节或多个先前图像样本的相应字节的函数，无论一个字节中是否有多个颜色分量，或者单个颜色分量是否跨越多个字节。

NOTE 2

这可以在牺牲一些压缩效果的情况下显著提高速度。

LZW and Flate encoding compress more compactly if their input data is highly predictable. One way of increasing the predictability of many continuous-tone sampled images is to replace each sample with the difference between that sample and a predictor function applied to earlier neighboring samples. If the predictor function works well, the postprediction data clusters toward 0.

PDF supports two groups of predictor functions. The first, the TIFF group, consists of the single function that is Predictor 2 in the TIFF 6.0 specification.

NOTE 1

(In the TIFF 6.0 specification, Predictor 2 applies only to LZW compression, but here it applies to Flate compression as well.) TIFF Predictor 2 predicts that each colour component of a sample is the same as the corresponding colour component of the sample immediately to its left.

The second supported group of predictor functions, the PNG group, consists of the filters of the World Wide Web Consortium’s Portable Network Graphics recommendation, documented in Internet RFC 2083, PNG (Portable Network Graphics) Specification (see the Bibliography).

The term predictors is used here instead of filters to avoid confusion.

There are five basic PNG predictor algorithms (and a sixth that chooses the optimum predictor function separately for each row).

Table 9 – PNG predictor algorithms
PNG Predictor Algorithms	Description
None	No prediction
Sub	Predicts the same as the sample to the left
Up	Predicts the same as the sample above
Average	Predicts the average of the sample to the left and the sample above
Paeth	A nonlinear function of the sample above, the sample to the left, and the sample to the upper left

The predictor algorithm to be used, if any, shall be indicated by the Predictor filter parameter (see [Table 8]#table8), whose value shall be one of those listed in Table 10.

For LZWDecode and FlateDecode, a Predictor value greater than or equal to 10 shall indicate that a PNG predictor is in use; the specific predictor function used shall be explicitly encoded in the incoming data. The value of Predictor supplied by the decoding filter need not match the value used when the data was encoded if they are both greater than or equal to 10.

Table 10 – Predictor values
Value	Meaning
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)

The two groups of predictor functions have some commonalities. Both make the following assumptions:

Data shall be presented in order, from the top row to the bottom row and, within a row, from left to right.
A row shall occupy a whole number of bytes, rounded up if necessary.
Samples and their components shall be packed into bytes from high-order to low-order bits.
All colour components of samples outside the image (which are necessary for predictions near the boundaries) shall be 0.

The predictor function groups also differ in significant ways:

The postprediction data for each PNG-predicted row shall begin with an explicit algorithm tag; therefore, different rows can be predicted with different algorithms to improve compression. TIFF Predictor 2 has no such identifier; the same algorithm applies to all rows.
The TIFF function group shall predict each colour component from the prior instance of that component, taking into account the number of bits per component and components per sample. In contrast, the PNG function group shall predict each byte of data as a function of the corresponding byte of one or more previous image samples, regardless of whether there are multiple colour components in a byte or whether a single colour component spans multiple bytes.

NOTE 2

This can yield significantly better speed at the cost of somewhat worse compression.

7.4.5 RunLengthDecode 过滤器¶

RunLengthDecode Filter

中文英文

RunLengthDecode 过滤器对基于行程长度的简单字节导向格式编码的数据进行解码。编码数据应为一系列行程，其中每个行程应由一个字节长度字节后跟1到128字节的数据组成。如果长度字节在0到127的范围内，则在解压缩期间，随后的长度 + 1（1到128）个字节将被直接复制。如果长度在129到255的范围内，则在解压缩期间，随后的单个字节将被复制257 - 长度（2到128）次。长度值为128应表示文件结束（EOD）。

NOTE

行程长度编码实现的压缩效果取决于输入数据。在最佳情况下（全部为零），对于长文件，大约可以实现64:1的压缩率。最坏的情况（十六进制序列00与FF交替）会导致128:127的扩展。

The RunLengthDecode filter decodes data that has been encoded in a simple byte-oriented format based on run length. The encoded data shall be a sequence of runs, where each run shall consist of a length byte followed by 1 to 128 bytes of data. If the length byte is in the range 0 to 127, the following length + 1 (1 to 128) bytes shall be copied literally during decompression. If length is in the range 129 to 255, the following single byte shall be copied 257 - length (2 to 128) times during decompression. A length value of 128 shall denote EOD.

NOTE

The compression achieved by run-length encoding depends on the input data. In the best case (all zeros), a compression of approximately 64 : 1 is achieved for long files. The worst case (the hexadecimal sequence 00 alternating with FF) results in an expansion of 127 : 128.

7.4.6 CCITTFaxDecode 过滤器¶

CCITTFaxDecode Filter

中文英文

CCITTFaxDecode 过滤器对使用 Group 3 或 Group 4 CCITT 传真编码的图像数据进行解码。

NOTE 1

CCITT 编码旨在实现低分辨率下单色（每个像素1位）图像数据的高效压缩，因此仅适用于位图图像数据，不适用于彩色图像、灰度图像或一般数据。

NOTE 2

CCITT 编码标准由国际电信联盟（ITU）定义，以前称为 Comité Consultatif International Téléphonique et Télégraphique（国际电话电报咨询委员会）。编码算法在本标准中没有详细描述，但可以在 ITU 建议书 T.4 和 T.6 中找到（见参考文献）。出于历史原因，我们称这些文档为 CCITT 标准。

CCITT 编码是面向比特的，而不是面向字节的。因此，原则上，编码或解码的数据不需要在字节边界结束。这个问题将通过以下方式处理：

未编码的数据应被视为完整的扫描线，在每个扫描线的末尾插入未使用的比特以填满最后一个字节。这种方法与 PDF 对采样图像数据的约定兼容。
编码数据通常被视为连续的、不间断的比特流。EncodedByteAlign 参数（在表11中描述）可用于使每个编码的扫描线填充到字节边界。

NOTE 3

尽管这不受 CCITT 标准的规范，传真机也从不这样做，但一些软件包发现以这种方式编码数据很方便。

当过滤器到达 EOD 时，它应始终跳转到编码数据之后的下一个字节边界。

过滤器不应执行任何错误校正或重新同步，除非如表11中DamagedRowsBeforeError参数所注明的。

表11列出了可用于控制解码的可选参数。除非另有说明，所有通过这些参数提供给解码过滤器的值应与编码数据时使用的值相匹配。

Table 11 – CCITTFaxDecode过滤器的可选参数
Key	Type	Value
K	integer	用于标识所使用的编码方案的代码： <0 纯二维编码（Group 4） =0 纯一维编码（Group 3, 1-D） >0 混合一维和二维编码（Group 3, 2-D），一维编码的行后面最多可以跟随 K - 1 行二维编码的行过滤器应区分 K 的负值、零值和正值以确定如何解释编码数据；但是，它不应区分不同的正 K 值。默认值：0。
EndOfLine	boolean	一个标志，指示编码中是否存在行结束位模式。CCITTFaxDecode 过滤器应始终接受行结束位模式。如果 EndOfLine 为 true，则编码中应存在行结束位模式。默认值：false。
EncodedByteAlign	boolean	一个标志，指示过滤器是否期望在每个编码行之前有额外的 0 位，以便该行以字节边界开始。如果为 true，则过滤器应跳过编码位，在字节边界处开始解码每行。如果为 false，则过滤器不应期望编码表示中有额外的位。默认值：false。
Columns	integer	图像的像素宽度。如果该值不是 8 的倍数，过滤器应将未编码图像的宽度调整到下一个 8 的倍数，以便每行都从字节边界开始。默认值：1728。
Rows	integer	图像的扫描线高度。如果该值为 0 或不存在，则图像的高度不是预先确定的，编码数据将由一个块结束模式终止或由过滤器数据的结束终止。默认值：0。
EndOfBlock	integer	一个标志，指示过滤器是否期望编码数据由块结束模式终止，覆盖 Rows 参数。如果为 false，则过滤器将在解码了 Rows 指示的行数或其数据耗尽时停止，以先发生者为准。块结束模式应为适用于 K 参数的 CCITT 传真块结束 (EOFB) 或返回控制 (RTC)。默认值：true。
BlackIs1	boolean	一个标志，指示 1 位是否被解释为黑色像素，0 位为白色像素，这与 PDF 对图像数据的正常约定相反。默认值：false。
DamagedRowsBeforeError	integer	在发生错误之前可以容忍的数据损坏行数。此条目仅适用于 EndOfLine 为 true 且 K 非负时。容忍损坏的行意味着通过搜索 EndOfLine 模式在编码数据中找到其结尾，然后如果前一行未损坏，则用前一行的解码数据替换，或者如果前一行也损坏，则用白色扫描线替换。默认值：0。

NOTE 4

使用CCITT编码实现的压缩效果取决于数据本身，以及各种可选参数的值。对于Group 3一维编码，在最佳情况下（全为零），每行扫描线压缩到4个字节，压缩因子取决于扫描线的长度。如果扫描线长300字节，可以实现大约75:1的压缩比率。最坏的情况，即图像由交替的1和0组成，会导致2:9的扩展。

The CCITTFaxDecode filter decodes image data that has been encoded using either Group 3 or Group 4 CCITT facsimile (fax) encoding.

NOTE 1

CCITT encoding is designed to achieve efficient compression of monochrome (1 bit per pixel) image data at relatively low resolutions, and so is useful only for bitmap image data, not for colour images, grayscale images, or general data.

NOTE 2

The CCITT encoding standard is defined by the International Telecommunications Union (ITU), formerly known as the Comité Consultatif International Téléphonique et Télégraphique (International Coordinating Committee for Telephony and Telegraphy). The encoding algorithm is not described in detail in this standard but can be found in ITU Recommendations T.4 and T.6 (see the Bibliography). For historical reasons, we refer to these documents as the CCITT standard.

CCITT encoding is bit-oriented, not byte-oriented. Therefore, in principle, encoded or decoded data need not end at a byte boundary. This problem shall be dealt with in the following ways:

Unencoded data shall be treated as complete scan lines, with unused bits inserted at the end of each scan line to fill out the last byte. This approach is compatible with the PDF convention for sampled image data.
Encoded data shall ordinarily be treated as a continuous, unbroken bit stream. The EncodedByteAlign parameter (described in Table 11) may be used to cause each encoded scan line to be filled to a byte boundary.

NOTE 3

Although this is not prescribed by the CCITT standard and fax machines never do this, some software packages find it convenient to encode data this way.
When a filter reaches EOD, it shall always skip to the next byte boundary following the encoded data.

The filter shall not perform any error correction or resynchronization, except as noted for the DamagedRowsBeforeError parameter in Table 11.

Table 11 lists the optional parameters that may be used to control the decoding. Except where noted otherwise, all values supplied to the decoding filter by any of these parameters shall match those used when the data was encoded.

Table 11 – Optional parameters for the CCITTFaxDecode filter
Key	Type	Value
K	integer	A code identifying the encoding scheme used: <0 Pure two-dimensional encoding (Group 4) =0 Pure one-dimensional encoding (Group 3, 1-D) >0 Mixed one- and two-dimensional encoding (Group 3, 2-D), in which a line encoded one-dimensionally may be followed by at most K − 1 lines encoded two-dimensionally The filter shall distinguish among negative, zero, and positive values of K to determine how to interpret the encoded data; however, it shall not distinguish between different positive K values. Default value: 0.
EndOfLine	boolean	A flag indicating whether end-of-line bit patterns shall be present in the encoding. The CCITTFaxDecode filter shall always accept end-of-line bit patterns. If EndOfLine is true end-of-line bit patterns shall be present.Default value: false.
EncodedByteAlign	boolean	A flag indicating whether the filter shall expect extra 0 bits before each encoded line so that the line begins on a byte boundary. If true, the filter shall skip over encoded bits to begin decoding each line at a byte boundary. If false, the filter shall not expect extra bits in the encoded representation. Default value: false.
Columns	integer	The width of the image in pixels. If the value is not a multiple of 8, the filter shall adjust the width of the unencoded image to the next multiple of 8 so that each line starts on a byte boundary. Default value: 1728.
Rows	integer	The height of the image in scan lines. If the value is 0 or absent, the image’s height is not predetermined, and the encoded data shall be terminated by an end-of-block bit pattern or by the end of the filter’s data. Default value: 0.
EndOfBlock	integer	A flag indicating whether the filter shall expect the encoded data to be terminated by an end-of-block pattern, overriding the Rows parameter. If false, the filter shall stop when it has decoded the number of lines indicated by Rows or when its data has been exhausted, whichever occurs first. The end-of- block pattern shall be the CCITT end-of-facsimile-block (EOFB) or return-to-control (RTC) appropriate for the K parameter. Default value: true.
BlackIs1	boolean	A flag indicating whether 1 bits shall be interpreted as black pixels and 0 bits as white pixels, the reverse of the normal PDF convention for image data. Default value: false.
DamagedRowsBeforeError	integer	The number of damaged rows of data that shall be tolerated before an error occurs. This entry shall apply only if EndOfLine is true and K is non-negative. Tolerating a damaged row shall mean locating its end in the encoded data by searching for an EndOfLine pattern and then substituting decoded data from the previous row if the previous row was not damaged, or a white scan line if the previous row was also damaged. Default value: 0.

NOTE 4

The compression achieved using CCITT encoding depends on the data, as well as on the value of various optional parameters. For Group 3 one-dimensional encoding, in the best case (all zeros), each scan line compresses to 4 bytes, and the compression factor depends on the length of a scan line. If the scan line is 300 bytes long, a compression ratio of approximately 75 : 1 is achieved. The worst case, an image of alternating ones and zeros, produces an expansion of 2 : 9.

7.4.7 JBIG2Decode 过滤器¶

JBIG2Decode Filter

中文英文

JBIG2Decode 过滤器（PDF 1.4）对使用 JBIG2 编码编码的单色（每个像素1位）图像数据进行解码。

NOTE 1

JBIG 代表联合双色图像专家组，这是国际标准化组织（ISO）内的一个小组，他们开发了这种格式。JBIG2 是最初作为 JBIG1 发布的标准的第二版。

JBIG2 编码提供了有损和无损压缩，仅适用于单色图像，不适用于彩色图像、灰度图像或一般数据。编码器使用的算法和格式的细节这里没有描述。请参阅 ISO/IEC 11544 发布的标准以获取当前的 JBIG2 规范。可以通过 JBIG 和 JPEG（联合图像专家组）委员会的网站 http://www.jpeg.org 获取更多信息。

通常，JBIG2 提供的压缩比现有的 CCITT 标准（在 7.4.6，"CCITTFaxDecode 过滤器" 中讨论）要好得多。它实现的压缩效果强烈依赖于图像的性质。包含任何语言文本的页面图像压缩效果特别好，对于满页文本的页面，典型的压缩比率为 20:1 到 50:1。

JBIG2 编码器应建立一个在图像中找到的唯一符号位图的表，图像中后面找到的符号将与该表进行匹配。匹配的符号将被替换为指向表的索引，未能匹配的符号将被添加到表中。表本身应使用其他方式进行压缩。

NOTE 2

对于经常重复相同符号的文档，这种方法可以产生高压缩比率，这是通过扫描文本页面创建的图像的典型情况。它还实现了图像中空白区域的高压缩，因为空白区域不包含符号，所以不需要编码。

虽然最佳压缩效果是针对文本图像实现的，但 JBIG2 标准也包括了用于压缩图像中包含点阵半色调图像（例如，照片）区域的算法。

JBIG2 压缩方法也可以用于将多个图像编码到单个 JBIG2 比特流中。

NOTE 3

通常，这些图像是多页文档的扫描页面。由于使用单个符号位图表在多个页面之间匹配符号，这种类型的编码可以实现比如果每页单独使用 JBIG2 编码更高的压缩比率。

通常，图像可以在 PDF 中指定为 图像 XObject 或内联图像（如 8.9，"图像" 中所述）；但是，JBIG2Decode 过滤器不应用于内联图像。

该过滤器通过将每个 JBIG2 页面表示为 PDF 图像来处理单页和多页 JBIG2 比特流，如下所示：

过滤器应使用 JBIG2 的嵌入式文件组织。（ISO 规范的附录中提供了有关此组织及其他类型文件组织的详细信息。）规范中提到的可选的2字节组合（标记）在 PDF 中不应使用。在随机访问组织中的 JBIG2 比特流应转换为嵌入式文件组织。顺序组织的比特流无需重新组织，除了下面描述的映射。
PDF 中不应使用 JBIG2 文件头、页结束段和文件结束段。在创建下面描述的 PDF 对象之前，应删除这些内容。
应用于 JBIG2Decode 过滤器的图像 XObject 应包含与该图像表示的 JBIG2 页面相关的所有段；即，所有段的页面关联字段包含图像表示的 JBIG2 页面的页码。但在图像 XObject 中，段的页码应始终为 1；即，当每个这样的段写入 XObject 时，其段页面关联字段的值应设置为 1。
如果比特流包含全局段（段的页面关联字段包含 0），这些段应放置在单独的 PDF 流中，并且表 12 中列出的过滤器参数应引用该流。该流可以由多个使用相同全局段的 JBIG2 编码的图像 XObject 共享。

Table 12 – JBIG2Decode 过滤器的可选参数
Key	Type	Value
JBIG2Globals	stream	包含 JBIG2 全局（页码0）段的流。即使只有一个 JBIG2 图像 XObject 引用它，全局段也应放置在此流中。

EXAMPLE 1

下面展示了一个使用 JBIG2 压缩方法压缩并用 ASCII 十六进制表示编码的图像。由于 JBIG2 比特流包含全局段，这些段被放置在单独的 PDF 流中，如 JBIG2Globals 过滤器参数所示。

5 0 obj
    << /Type /XObject
       /Subtype /Image
       /Width 52
       /Height 66
       /ColorSpace /DeviceGray
       /BitsPerComponent 1
       /Length 224
       /Filter [ /ASCIIHexDecode /JBIG2Decode ]
       /DecodeParms [ null << /JBIG2Globals 6 0 R >> ]
    >>
stream
000000013000010000001300000034000000420000000000
00000040000000000002062000010000001e000000340000
004200000000000000000200100000000231db51ce51ffac >
endstream
endobj

6 0 obj
    << /Length 126
       /Filter /ASCIIHexDecode
    >>
stream
0000000000010000000032000003fffdff02fefefe000000
01000000012ae225aea9a5a538b4d9999c5c8e56ef0f872
7f2b53d4e37ef795cc5506dffac >
endstream
endobj

这个例子的JBIG2比特流如下：

EXAMPLE 2

97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01 00 00 00 00 00 01 00 00 00 00 32
00 00 03 FF FD FF 02 FE FE FE 00 00 00 01 00 00 00 01 2A E2 25 AE A9 A5
A5 38 B4 D9 99 9C 5C 8E 56 EF 0F 87 27 F2 B5 3D 4E 37 EF 79 5C C5 50 6D
FF AC 00 00 00 01 30 00 01 00 00 00 13 00 00 00 34 00 00 00 42 00 00 00
00 00 00 00 00 40 00 00 00 00 00 02 06 20 00 01 00 00 00 1E 00 00 00 34
00 00 00 42 00 00 00 00 00 00 00 00 02 00 10 00 00 00 02 31 DB 51 CE 51
FF AC 00 00 00 03 31 00 01 00 00 00 00 00 00 00 04 33 01 00 00 00 00

这个比特流由以下部分组成（按列出的顺序）：

JBIG2文件头

97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01

由于JBIG2文件头在PDF中不使用，因此这个头部没有放在JBIG2流对象中，被丢弃了。
第一个JBIG2段（段0）—在这种情况下，是符号字典段

00 00 00 00 00 01 00 00 00 00 32 00 00 03 FF FD FF 02 FE FE FE 00 00 00 01 00 00 00 01 2A E2 25 AE A9 A5 A5 38 B4 D9 99 9C 5C 8E 56 EF 0F 87 27 F2 B5 3D 4E 37 EF 79 5C C5 50 6D FF AC

这是一个全局段（段页面关联=0），因此应该放在JBIG2Globals流中。
页面信息段

00 00 00 01 30 00 01 00 00 00 13 00 00 00 34 00 00 00 42 00 00 00 00 00 00 00 00 40 00 00

和立即文本区域段

00 00 00 02 06 20 00 01 00 00 00 1E 00 00 00 34 00 00 00 42 00 00 00 00 00 00 00 00 02 00 10 00 00 00 02 31 DB 51 CE 51 FF AC

这两个段构成了JBIG2页面的内容，应该放在代表这张图片的PDF XObject中。
页面结束段

00 00 00 03 31 00 01 00 00 00 00

和文件结束段

00 00 00 04 33 01 00 00 00 00

由于这些段在PDF中不使用，它们被丢弃了。

因此，生成的PDF图像对象包含了页面信息段和立即文本区域段，并引用了一个包含符号字典段的JBIG2Globals流。

The JBIG2Decode filter (PDF 1.4) decodes monochrome (1 bit per pixel) image data that has been encoded using JBIG2 encoding.

NOTE 1

JBIG stands for the Joint Bi-Level Image Experts Group, a group within the International Organization for Standardization (ISO) that developed the format. JBIG2 is the second version of a standard originally released as JBIG1.

JBIG2 encoding, which provides for both lossy and lossless compression, is useful only for monochrom images, not for colour images, grayscale images, or general data. The algorithms used by the encoder, and the details of the format, are not described here. See ISO/IEC 11544 published standard for the current JBIG2 specification. Additional information can be found through the Web site for the JBIG and JPEG (Joint Photographic Experts Group) committees at <http://www.jpeg.org>.

In general, JBIG2 provides considerably better compression than the existing CCITT standard (discussed in 7.4.6, "CCITTFaxDecode Filter"). The compression it achieves depends strongly on the nature of the image. Images of pages containing text in any language compress particularly well, with typical compression ratios of 20:1 to 50:1 for a page full of text.

The JBIG2 encoder shall build a table of unique symbol bitmaps found in the image, and other symbols found later in the image shall be matched against the table. Matching symbols shall be replaced by an index into the table, and symbols that fail to match shall be added to the table. The table itself shall be compressed using other means.

NOTE 2

This method results in high compression ratios for documents in which the same symbol is repeated often, as is typical for images created by scanning text pages. It also results in high compression of white space in the image, which does not need to be encoded because it contains no symbols.

While best compression is achieved for images of text, the JBIG2 standard also includes algorithms for compressing regions of an image that contain dithered halftone images (for example, photographs).

The JBIG2 compression method may also be used for encoding multiple images into a single JBIG2 bit stream.

NOTE 3

Typically, these images are scanned pages of a multiple-page document. Since a single table of symbol bitmaps is used to match symbols across multiple pages, this type of encoding can result in higher compression ratios than if each of the pages had been individually encoded using JBIG2.

In general, an image may be specified in PDF as either an image XObject or an inline image (as described in 8.9, "Images"); however, the JBIG2Decode filter shall not be used with inline images.

This filter addresses both single-page and multiple-page JBIG2 bit streams by representing each JBIG2 page as a PDF image, as follows:

The filter shall use the embedded file organization of JBIG2. (The details of this and the other types of file organization are provided in an annex of the ISO specification.) The optional 2-byte combination (marker) mentioned in the specification shall not be used in PDF. JBIG2 bit streams in random-access organization should be converted to the embedded file organization. Bit streams in sequential organization need no reorganization, except for the mappings described below.
The JBIG2 file header, end-of-page segments, and end-of-file segment shall not be used in PDF. These should be removed before the PDF objects described below are created.
The image XObject to which the JBIG2Decode filter is applied shall contain all segments that are associated with the JBIG2 page represented by that image; that is, all segments whose segment page association field contains the page number of the JBIG2 page represented by the image. In the image XObject, however, the segment’s page number should always be 1; that is, when each such segment is written to the XObject, the value of its segment page association field should be set to 1.
If the bit stream contains global segments (segments whose segment page association field contains 0), these segments shall be placed in a separate PDF stream, and the filter parameter listed in Table 12 should refer to that stream. The stream can be shared by multiple image XObjects whose JBIG2 encodings use the same global segments.

Table 12 – Optional parameter for the JBIG2Decode filter
Key	Type	Value
JBIG2Globals	stream	A stream containing the JBIG2 global (page 0) segments. Global segments shall be placed in this stream even if only a single JBIG2 image XObject refers to it.

EXAMPLE 1

The following shows an image that was compressed using the JBIG2 compression method and then encoded in ASCII hexadecimal representation. Since the JBIG2 bit stream contains global segments, these segments are placed in a separate PDF stream, as indicated by the JBIG2Globals filter parameter.

5 0 obj
    << /Type /XObject
       /Subtype /Image
       /Width 52
       /Height 66
       /ColorSpace /DeviceGray
       /BitsPerComponent 1
       /Length 224
       /Filter [ /ASCIIHexDecode /JBIG2Decode ]
       /DecodeParms [ null << /JBIG2Globals 6 0 R >> ]
    >>
stream
000000013000010000001300000034000000420000000000
00000040000000000002062000010000001e000000340000
004200000000000000000200100000000231db51ce51ffac >
endstream
endobj

6 0 obj
    << /Length 126
       /Filter /ASCIIHexDecode
    >>
stream
0000000000010000000032000003fffdff02fefefe000000
01000000012ae225aea9a5a538b4d9999c5c8e56ef0f872
7f2b53d4e37ef795cc5506dffac >
endstream
endobj

The JBIG2 bit stream for this example is as follows:

EXAMPLE 2

97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01 00 00 00 00 00 01 00 00 00 00 32
00 00 03 FF FD FF 02 FE FE FE 00 00 00 01 00 00 00 01 2A E2 25 AE A9 A5
A5 38 B4 D9 99 9C 5C 8E 56 EF 0F 87 27 F2 B5 3D 4E 37 EF 79 5C C5 50 6D
FF AC 00 00 00 01 30 00 01 00 00 00 13 00 00 00 34 00 00 00 42 00 00 00
00 00 00 00 00 40 00 00 00 00 00 02 06 20 00 01 00 00 00 1E 00 00 00 34
00 00 00 42 00 00 00 00 00 00 00 00 02 00 10 00 00 00 02 31 DB 51 CE 51
FF AC 00 00 00 03 31 00 01 00 00 00 00 00 00 00 04 33 01 00 00 00 00

This bit stream is made up of the following parts (in the order listed):

The JBIG2 file header

97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01

Since the JBIG2 file header shall not used in PDF, this header is not placed in the JBIG2 stream object and is discarded.
The first JBIG2 segment (segment 0)—in this case, the symbol dictionary segment

00 00 00 00 00 01 00 00 00 00 32 00 00 03 FF FD FF 02 FE FE FE 00 00 00 01 00 00 00 01 2A E2 25 AE A9 A5 A5 38 B4 D9 99 9C 5C 8E 56 EF 0F 87 27 F2 B5 3D 4E 37 EF 79 5C C5 50 6D FF AC

This is a global segment (segment page association = 0) and so shall be placed in the JBIG2Globals stream.
The page information segment

00 00 00 01 30 00 01 00 00 00 13 00 00 00 34 00 00 00 42 00 00 00 00 00 00 00 00 40 00 00

and the immediate text region segment

00 00 00 02 06 20 00 01 00 00 00 1E 00 00 00 34 00 00 00 42 00 00 00 00 00 00 00 00 02 00 10 00 00 00 02 31 DB 51 CE 51 FF AC

These two segments constitute the contents of the JBIG2 page and shall be placed in the PDF XObject representing this image.
The end-of-page segment

00 00 00 03 31 00 01 00 00 00 00

and the end-of-file segment

00 00 00 04 33 01 00 00 00 00

Since these segments shall not be used in PDF, they are discarded.

The resulting PDF image object, then, contains the page information segment and the immediate text region segment and refers to a JBIG2Globals stream that contains the symbol dictionary segment.

7.4.8 DCTDecode 过滤器¶

DCTDecode Filter

中文英文

DCTDecode 过滤器解码以 JPEG 基线格式编码的灰度或彩色图像数据。有关 JPEG “标记” 使用的更多信息，请参见 Adobe 技术说明 #5116。

NOTE 1

JPEG 代表联合图像专家组，这是国际标准化组织内的一个小组，负责开发该格式；DCT 代表离散余弦变换，这是编码中使用的主要技术。

JPEG 编码是一种有损压缩方法，专门设计用于压缩采样的连续色调图像，而不是用于通用数据压缩。

使用 JPEG 编码的数据应由图像样本流组成，每个样本包含一个、两个、三个或四个颜色分量。特定样本的颜色分量值应连续出现。每个分量值应占用一个字节。

在编码过程中，几个参数将控制算法和信息损失。这些参数的值，包括图像的尺寸和每个样本的分量数，完全由编码器控制，并应存储在编码数据中。DCTDecode 可以直接从编码数据中获取它需要的参数值。然而，在一个实例中，参数不需要出现在编码数据中，而应在过滤器参数字典中指定；见表 13。

NOTE 2

这里没有介绍编码算法的细节，但它们在 ISO 标准和《JPEG：静态图像数据压缩标准》中有所描述，该书由 Pennebaker 和 Mitchell 编写（见参考文献）。简单来说，JPEG 算法将图像分解成 8 个样本宽和 8 个样本高的块。图像中的每个颜色分量分别处理。对每个块执行二维 DCT。这个操作产生 64 个系数，然后进行量化。每个系数可以使用不同的步长进行量化。正是这种量化导致了 JPEG 算法中的信息损失。量化后的系数随后被压缩。

Table 13 – DCTDecode 过滤器的可选参数
Key	Type	Value
ColorTransform	integer	（可选）一个代码，指定应在样本值上执行的转换： 0 无转换。 1 如果图像有三个颜色分量，RGB值在编码前应转换为YUV，在解码后从YUV转换回RGB。如果图像有四个分量，CMYK值在编码前应转换为YUVK，在解码后从YUVK转换回CMYK。如果图像有一个或两个颜色分量，则应忽略此选项。如果编码算法在编码数据中插入了Adobe定义的标记代码，指示ColorTransform值，则应在执行DCT解码后根据编码数据中提供的值进行颜色转换，或者不转换，此字典条目的值将被忽略。如果在编码数据中没有Adobe定义的标记代码指示ColorTransform值，则将使用此字典条目中指定的值。如果在编码数据中没有Adobe定义的标记代码指示ColorTransform值，并且此字典条目不在过滤器字典中，则默认的ColorTransform值将是1，如果图像有三个分量，否则为0。 a 控制解码过程的参数以及其他元数据是使用一种称为“标记”的符号嵌入到编码数据流中的。当Adobe系统公司定义了在PostScript数据流中使用JPEG图像时，它定义了一套特定的规则，涉及哪些标记应被识别，哪些应被忽略，哪些被视为错误。还引入了一个特定的Adobe定义的标记。在Adobe技术说明 #5116（参考）中提供了在PostScript中生成和使用DCT编码数据的确切规则。PDF DCT 编码应严格遵循Adobe为PostScript建立的规则。

NOTE 3

编码算法可以通过在量化过程中减小步长来减少信息损失，代价是减少算法实现的压缩量。JPEG算法实现的压缩取决于被压缩的图像以及可接受的信息损失量。一般来说，可以在不察觉信息损失的情况下实现15:1的压缩比，而30:1的压缩比会导致图像质量的轻微下降。

NOTE 4

通常，对于分别处理亮度和色度的颜色空间，可以实现比不分别处理的颜色空间更好的压缩。过滤器提供的RGB到YUV的转换是一次尝试分离亮度和色度的努力；它符合CCIR建议601-1。其他颜色空间，如CIE 1976 L*a*b*空间，也可能实现这一目标。然后可以通过使用较粗的采样或量化来更多地压缩色度分量而不是亮度分量，而不会降低质量。

除了基线JPEG格式，从PDF 1.3开始，DCTDecode过滤器将支持渐进式JPEG扩展。这个扩展不会向DCTDecode参数字典添加任何条目；基线和渐进式JPEG之间的区别将在编码数据中表示。

NOTE 5

对于嵌入在PDF文件中的流数据，使用渐进式JPEG没有任何好处。解码渐进式JPEG比基线JPEG更慢，并且消耗更多的内存。这个功能的目的是为了使流能够引用一个数据已经是以渐进式JPEG编码的外部文件。

The DCTDecode filter decodes grayscale or colour image data that has been encoded in the JPEG baseline format. See Adobe Technical Note #5116 for additional information about the use of JPEG “markers.”

NOTE 1

JPEG stands for the Joint Photographic Experts Group, a group within the International Organization for Standardization that developed the format; DCT stands for discrete cosine transform, the primary technique used in the encoding.

JPEG encoding is a lossy compression method, designed specifically for compression of sampled continuous-tone images and not for general data compression.

Data to be encoded using JPEG shall consist of a stream of image samples, each consisting of one, two, three, or four colour components. The colour component values for a particular sample shall appear consecutively. Each component value shall occupy a byte.

During encoding, several parameters shall control the algorithm and the information loss. The values of thes parameters, which include the dimensions of the image and the number of components per sample, are entirel under the control of the encoder and shall be stored in the encoded data. DCTDecode may obtain th parameter values it requires directly from the encoded data. However, in one instance, the parameter need no be present in the encoded data but shall be specified in the filter parameter dictionary; see Table 13.

NOTE 2

The details of the encoding algorithm are not presented here but are in the ISO standard and in JPEG: Still Image Data Compression Standard, by Pennebaker and Mitchell (see the Bibliography). Briefly, the JPEG algorithm breaks an image up into blocks that are 8 samples wide by 8 samples high. Each colour component in an image is treated separately. A two-dimensional DCT is performed on each block. This operation produces 64 coefficients, which are then quantized. Each coefficient may be quantized with a different step size. It is this quantization that results in the loss of information in the JPEG algorithm. The quantized coefficients are then compressed.

Table 13 – Optional parameter for the DCTDecode filter
Key	Type	Value
ColorTransform	integer	(Optional) A code specifying the transformation that shall be performed on the sample values: 0 No transformation. 1 If the image has three colour components, RGB values shall be transformed to YUV before encoding and from YUV to RGB after decoding. If the image has four components, CMYK values shall be transformed to YUVK before encoding and from YUVK to CMYK after decoding. This option shall be ignored if the image has one or two colour components. If the encoding algorithm has inserted the Adobe-defined markera code in the encoded data indicating the ColorTransform value, then the colours shall be transformed, or not, after the DCT decoding has been performed according to the value provided in the encoded data and the value of this dictionary entry shall be ignored. If the Adobe- defined marker code in the encoded data indicating the ColorTransform value is not present then the value specified in this dictionary entry will be used. If the Adobe-defined marker code in the encoded data indicating the ColorTransform value is not present and this dictionary entry is not present in the filter dictionary then the default value of ColorTransform shall be 1 if the image has three components and 0 otherwise. a Parameters that control the decoding process as well as other metadata is embedded within the encoded data stream using a notation referred to as “markers”. When it defined the use of JPEG images within PostScript data streams, Adobe System Incorporated defined a particular set of rules pertaining to which markers are to be recognized, which are to be ignored and which are considered errors. A specific Adobe-defined marker was also introduced. The exact rules for producing and consuming DCT encoded data within PostScript are provide in Adobe Technical Note #5116 (reference). PDF DCT Encoding shall exactly follow those rules established by Adobe for PostScript.

NOTE 3

The encoding algorithm can reduce the information loss by making the step size in the quantization smaller at the expense of reducing the amount of compression achieved by the algorithm. The compression achieved by the JPEG algorithm depends on the image being compressed and the amount of loss that is acceptable. In general, a compression of 15 : 1 can be achieved without perceptible loss of information, and 30 : 1 compression causes little impairment of the image.

NOTE 4

Better compression is often possible for colour spaces that treat luminance and chrominance separately than for those that do not. The RGB-to-YUV conversion provided by the filters is one attempt to separate luminance and chrominance; it conforms to CCIR recommendation 601-1. Other colour spaces, such as the CIE 1976 L*a*b* space, may also achieve this objective. The chrominance components can then be compressed more than the luminance by using coarser sampling or quantization, with no degradation in quality.

In addition to the baseline JPEG format, beginning with PDF 1.3, the DCTDecode filter shall support the progressive JPEG extension. This extension does not add any entries to the DCTDecode parameter dictionary; the distinction between baseline and progressive JPEG shall be represented in the encoded data.

NOTE 5

There is no benefit to using progressive JPEG for stream data that is embedded in a PDF file. Decoding progressive JPEG is slower and consumes more memory than baseline JPEG. The purpose of this feature is to enable a stream to refer to an external file whose data happens to be already encoded in progressive JPEG.

7.4.9 JPXDecode 过滤器¶

JPXDecode Filter

中文英文

JPXDecode 过滤器（PDF 1.5）使用 JPEG2000 压缩方法解码数据，这是一种用于压缩和封装图像数据的 ISO 标准。

NOTE 1

JPEG2000 定义了一种基于小波的图像压缩方法，与其他方法（如常规 JPEG 或 CCITT）相比，它提供了更好的尺寸缩减。尽管过滤器可以再现无损压缩的样本。

此过滤器仅应用于图像 XObjects，不适用于内联图像（见 8.9，"Images"）。它既适用于具有单一颜色分量的图像，也适用于具有多个颜色分量的图像。图像中的颜色分量可以有不同的样本位数。允许的值从 1 到 38。

NOTE 2

从单个 JPEG2000 数据流中，可以解码图像的多个版本。这些不同版本沿着四个自由度形成渐进：采样分辨率、颜色深度、波段和位置。例如，通过分辨率渐进，可以从数据中解码图像的缩略图版本，然后是图像的其他版本序列，每个版本大约有前一个版本的四倍样本（宽度的两倍乘以高度的两倍）。最后一个版本是全分辨率图像。

NOTE 3

查看和打印应用程序可以通过使用分辨率渐进来获得性能优势。如果全分辨率图像采样密集，应用程序可能能够选择并仅解码构成较低分辨率版本的数据，从而减少解码时间。需要处理的字节更少，特别是当通过 Web 查看文件时，这是一个特别的好处。如果只需要显示或打印图像的某些区域，图像的平铺结构也可能提供好处。

NOTE 4

关于这些渐进的信息被编码在数据中；不需要解码参数来描述它们。解码器处理它遇到的任何渐进，以提供正确的图像数据。不感兴趣的渐进可能只是有性能后果。

JPEG2000 规范定义了两种广泛使用的格式，JP2 和 JPX，用于打包压缩的图像数据。JP2 是 JPX 的一个子集。这些封装包含了正确解释图像数据所需的所有必要信息，包括颜色空间、每个分量的位和图像尺寸。换句话说，它们是图像的完整描述（与需要外部参数才能正确解释的图像数据相对）。JPXDecode 过滤器期望读取完整的 JPX 文件结构——无论是在 PDF 文件内部还是作为外部文件。

NOTE 5

为了促进互操作性，规范定义了一个称为 JPX 基线的 JPX 子集（JP2 也是其子集）。JPX 基线功能的完整细节包含在 ISO/IEC 15444-2 中，信息技术—JPEG 2000 图像编码系统：扩展（见参考文献）。有关更多信息，请参阅 <http://www.jpeg.org/jpeg2000/>。

PDF 图像 XObjects 使用的数据应限于 JPX 基线功能集，除了枚举颜色空间 19（CIEJab）。此外，枚举颜色空间 12（CMYK），它是 JPX 的一部分但不是 JP 基线的一部分，在 PDF 中也应得到支持。

JPX 文件描述了图像数据中存在的通道集合。一个通道可能有三种类型之一：

一个普通(ordinary)通道包含的值，在解码后，应成为指定颜色分量的样本。
一个透明度(opacity)通道提供应被解释为原始透明度信息的样本。
一个预乘透明度(premultiplied opacity)通道应提供已经被乘入与之关联的颜色通道的颜色样本的样本。

透明度和预乘透明度通道应与特定的颜色通道关联。对于给定的颜色通道，不应有超过一个透明度通道（任何类型）与之关联。

EXAMPLE

一个透明度通道可能适用于红色样本，另一个透明度通道适用于 RGB 图像的绿色和蓝色颜色通道。

NOTE 6

使用透明度信息的方法明确没有指定，尽管一种可能的方法显示了正常的混合模式。

除了使用透明度通道描述透明度外，JPX 文件还有能力指定色度键透明度。可以通过给出一个值数组来指定单一颜色，每个颜色通道一个值。任何与此颜色匹配的图像位置都应被视为完全透明。

JPX 文件中的图像可能有以下颜色空间之一：

从枚举颜色空间列表中选择的预定义颜色空间。（其中两个实际上是颜色空间家族，并包含了参数。）
受限的 ICC 配置文件。这些是 JP2 文件中唯一允许的 ICC 配置文件类型。
ICC-1 定义的任何类型的输入 ICC 配置文件。
供应商定义的颜色空间。

图像可以指定多个颜色空间，每个空间都标记有优先级和近似值，这表明它代表首选颜色空间的程度。此外，图像的颜色空间可以作为使用来自图像数据通道的样本选择的颜色调色板的基础：相当于 PDF 中的索引颜色空间。

JPX 格式的其他功能超出了描述简单图像的范围。这些包括用于描述分层和提供组成指令、指定简单动画和包括通用 XML 元数据（以及 JPEG2000 特定模式的此类数据）的规定。相关的元数据应在图像字典的元数据流中以 XMP 格式复制（见 14.3.2，"元数据流"）。

当使用 JPXDecode 过滤器与图像 XObjects 时，图像字典中的一些条目将适用以下更改和限制（有关这些条目的详细信息，见 8.9.5，"Image Dictionaries"）：

Width 和 Height 应与 JPEG2000 数据中的相应宽度和高度值相匹配。
ColorSpace 是可选的，因为 JPEG2000 数据包含颜色空间规格。如果出现，它将决定图像样本的解释方式，JPEG2000 数据中的颜色空间规格将被忽略。JPEG2000 数据中的颜色通道数应与颜色空间中的组件数相匹配；合规的编写器应确保样本与使用的颜色空间一致。
可以指定除 Pattern 之外的任何颜色空间。如果使用 Indexed 颜色空间，它应受 PDF 256 种颜色的限制。如果颜色空间与 JPX 的枚举颜色空间不匹配（例如，如果它有两个或更多的颜色组件），则应在 JPX 数据中作为供应商颜色空间指定。
如果图像字典中没有 ColorSpace，则应使用 JPEG2000 数据中的颜色空间信息。PDF 中的 JPEG2000 图像应具有以下之一：基线 JPX 颜色空间；枚举颜色空间 19（CIEJab）或枚举颜色空间 12（CMYK）；或至少一个在 PDF 中有效的 ICC 配置文件。合规的 PDF 阅读器应支持 JPX 基线的枚举颜色空间集；它们还应负责处理颜色空间和样本位深度之间的交互。
如果 JPEG2000 数据中给出了多个颜色空间规格，合规的阅读器应尝试使用优先级最高且近似值最好的那个。如果颜色空间由不支持的 ICC 配置文件给出，则应使用优先级和近似值较低的下一个颜色空间。如果找不到支持的颜色空间，则使用的颜色空间应为 DeviceGray、DeviceRGB 或 DeviceCMYK，具体取决于 JPEG2000 数据中的通道数是 1、3 还是 4。
SMaskInData 指定是否使用与图像样本打包在一起的软蒙版信息（见 11.6.5.3，"Soft-Mask Images"）；如果是，SMask 条目不应出现。如果 SMaskInData 非零，则 JPEG2000 数据中应只有一个透明度通道，并且它应用于所有颜色通道。
Decode 将被忽略，除非图像被视为蒙版；也就是说，当 ImageMask 为 true 时。在这种情况下，JPEG2000 数据应提供一个单一颜色通道，样本为 1 位。

The JPXDecode filter (PDF 1.5) decodes data that has been encoded using the JPEG2000 compression method, an ISO standard for the compression and packaging of image data.

NOTE 1

JPEG2000 defines a wavelet-based method for image compression that gives somewhat better size reduction than other methods such as regular JPEG or CCITT. Although the filter can reproduce samples that are losslessly compressed.

This filter shall only be applied to image XObjects, and not to inline images (see 8.9, "Images"). It is suitable both for images that have a single colour component and for those that have multiple colour components. The colour components in an image may have different numbers of bits per sample. Any value from 1 to 38 shall be allowed.

NOTE 2

From a single JPEG2000 data stream, multiple versions of an image may be decoded. These different versions form progressions along four degrees of freedom: sampling resolution, colour depth, band, and location. For example, with a resolution progression, a thumbnail version of the image may be decoded from the data, followed by a sequence of other versions of the image, each with approximately four times as many samples (twice the width times twice the height) as the previous one. The last version is the full-resolution image.

NOTE 3

Viewing and printing applications may gain performance benefits by using the resolution progression. If the full-resolution image is densely sampled, the application may be able to select and decode only the data making up a lower-resolution version, thereby spending less time decoding. Fewer bytes need be processed, a particular benefit when viewing files over the Web. The tiling structure of the image may also provide benefits if only certain areas of an image need to be displayed or printed.

NOTE 4

Information on these progressions is encoded in the data; no decode parameters are needed to describe them. The decoder deals with any progressions it encounters to deliver the correct image data. Progressions that are of no interest may simply have performance consequences.

The JPEG2000 specifications define two widely used formats, JP2 and JPX, for packaging the compressed image data. JP2 is a subset of JPX. These packagings contain all the information needed to properly interpret the image data, including the colour space, bits per component, and image dimensions. In other words, they are complete descriptions of images (as opposed to image data that require outside parameters for correct interpretation). The JPXDecode filter shall expect to read a full JPX file structure—either internal to the PDF file or as an external file.

NOTE 5

To promote interoperability, the specifications define a subset of JPX called JPX baseline (of which JP2 is also a subset). The complete details of the baseline set of JPX features are contained in ISO/IEC 15444-2, Information Technology—JPEG 2000 Image Coding System: Extensions (see the Bibliography). See also <http://www.jpeg.org/jpeg2000/>.

Data used in PDF image XObjects shall be limited to the JPX baseline set of features, except for enumerate colour space 19 (CIEJab). In addition, enumerated colour space 12 (CMYK), which is part of JPX but not JP baseline, shall be supported in a PDF.

A JPX file describes a collection of channels that are present in the image data. A channel may have one of three types:

An ordinary channel contains values that, when decoded, shall become samples for a specified colour component.
An opacity channel provides samples that shall be interpreted as raw opacity information.
A premultiplied opacity channel shall provide samples that have been multiplied into the colour samples of those channels with which it is associated.

Opacity and premultiplied opacity channels shall be associated with specific colour channels. There shall not be more than one opacity channel (of either type) associated with a given colour channel.

EXAMPLE

It is possible for one opacity channel to apply to the red samples and another to apply to the green and blue colour channels of an RGB image.

NOTE 6

The method by which the opacity information is to be used is explicitly not specified, although one possible method shows a normal blending mode.

In addition to using opacity channels for describing transparency, JPX files also have the ability to specify chroma-key transparency. A single colour may be specified by giving an array of values, one value for each colour channel. Any image location that matches this colour shall be considered to be completely transparent.

Images in JPX files may have one of the following colour spaces:

A predefined colour space, chosen from a list of enumerated colour spaces. (Two of these are actually families of spaces and parameters are included.)
A restricted ICC profile. These are the only sorts of ICC profiles that are allowed in JP2 files.
An input ICC profile of any sort defined by ICC-1.
A vendor-defined colour space.

More than one colour space may be specified for an image, with each space being tagged with a precedence and an approximation value that indicates how well it represents the preferred colour space. In addition, the image’s colour space may serve as the foundation for a palette of colours that are selected using samples coming from the image’s data channels: the equivalent of an Indexed colour space in PDF.

There are other features in the JPX format beyond describing a simple image. These include provisions for describing layering and giving instructions on composition, specifying simple animation, and including generic XML metadata (along with JPEG2000-specific schemas for such data). Relevant metadata should be replicated in the image dictionary’s Metadata stream in XMP format (see 14.3.2, "Metadata Streams").

When using the JPXDecode filter with image XObjects, the following changes to and constraints on some entries in the image dictionary shall apply (see 8.9.5, "Image Dictionaries" for details on these entries):

Width and Height shall match the corresponding width and height values in the JPEG2000 data.
ColorSpace shall be optional since JPEG2000 data contain colour space specifications. If present, it shall determine how the image samples are interpreted, and the colour space specifications in the JPEG2000 data shall be ignored. The number of colour channels in the JPEG2000 data shall match the number of components in the colour space; a conforming writer shall ensure that the samples are consistent with the colour space used.
Any colour space other than Pattern may be specified. If an Indexed colour space is used, it shall be subject to the PDF limit of 256 colours. If the colour space does not match one of JPX’s enumerated colour spaces (for example, if it has two colour components or more than four), it should be specified as a vendor colour space in the JPX data.
If ColorSpace is not present in the image dictionary, the colour space information in the JPEG2000 data shall be used. A JPEG2000 image within a PDF shall have one of: the baseline JPX colorspaces; or enumerated colorspace 19 (CIEJab) or enumerated colorspace 12 (CMYK); or at least one ICC profile that is valid within PDF. Conforming PDF readers shall support the JPX baseline set of enumerated colour spaces; they shall also be responsible for dealing with the interaction between the colour spaces and the bit depth of samples.
If multiple colour space specifications are given in the JPEG2000 data, a conforming reader should attempt to use the one with the highest precedence and best approximation value. If the colour space is given by an unsupported ICC profile, the next lower colour space, in terms of precedence and approximation value, shall be used. If no supported colour space is found, the colour space used shall be DeviceGray, DeviceRGB, or DeviceCMYK, depending on the whether the number of channels in the JPEG2000 data is 1,3, or 4.
SMaskInData specifies whether soft-mask information packaged with the image samples shall be used (see 11.6.5.3, "Soft-Mask Images"); if it is, the SMask entry shall not be present. If SMaskInData is nonzero, there shall be only one opacity channel in the JPEG2000 data and it shall apply to all colour channels.
Decode shall be ignored, except in the case where the image is treated as a mask; that is, when ImageMask is true. In this case, the JPEG2000 data shall provide a single colour channel with 1-bit samples.

7.4.10 Crypt 过滤器¶

Crypt Filter

中文英文

Crypt 过滤器（PDF 1.5）允许文档级安全处理器（见 7.6，"Encryption"）确定用于解密输入数据的算法。此过滤器的解码参数字典中的 Name 参数（见表 14）应指定要使用的命名加密过滤器。Crypt 过滤器应是 Filter 数组条目中的第一个过滤器。

表 14 – Crypt 过滤器的可选参数
键	类型	值
Type	name	（可选）如果存在，对于 Crypt 过滤器解码参数字典应为 CryptFilterDecodeParms。
Name	name	（可选）要用于解密此流的加密过滤器的名称。名称应与加密字典的 CF 条目中的一个条目相对应（见表 20）或一个标准加密过滤器（见表 26）。默认值：Identity。

此外，解码参数字典可能包括对安全处理器私有的条目。安全处理器在使用信息解密数据或提供解密数据的密钥时，可能会使用来自加密过滤器解码参数字典和加密过滤器字典的信息（见表 25）。

NOTE

安全处理器在向解码参数字典添加私有数据时，应按照 PDF 名称注册表的规范命名这些条目（见附录 E）。

如果流指定了加密过滤器，那么安全处理器在解密流之前，不会将 7.6.2 中的 "算法 1：使用 RC4 或 AES 算法加密数据" 应用于密钥。相反，安全处理器应直接使用密钥解密流。小节 7.4，"Filters," 解释了流如何指定过滤器。

The Crypt filter (PDF 1.5) allows the document-level security handler (see 7.6, "Encryption") to determine which algorithms should be used to decrypt the input data. The Name parameter in the decode parameters dictionary for this filter (see Table 14) shall specify which of the named crypt filters in the document (see 7.6.5, "Crypt Filters") shall be used. The Crypt filter shall be the first filter in the Filter array entry.

Table 14 – Optional parameters for Crypt filters
Key	Type	Value
Type	name	(Optional) If present, shall be CryptFilterDecodeParms for a Crypt filter decode parameter dictionary.
Name	name	(Optional) The name of the crypt filter that shall be used to decrypt this stream. The name shall correspond to an entry in the CF entry of the encryption dictionary (see Table 20) or one of the standard crypt filters (see Table 26). Default value: Identity.

In addition, the decode parameters dictionary may include entries that are private to the security handler. Security handlers may use information from both the crypt filter decode parameters dictionary and the crypt filter dictionaries (see Table 25) when decrypting data or providing a key to decrypt data.

NOTE

When adding private data to the decode parameters dictionary, security handlers should name these entries in conformance with the PDF name registry (see Annex E).

If a stream specifies a crypt filter, then the security handler does not apply "Algorithm 1: Encryption of data using the RC4 or AES algorithms" in 7.6.2, "General Encryption Algorithm," to the key prior to decrypting the stream. Instead, the security handler shall decrypt the stream using the key as is. Sub-clause 7.4, "Filters," explains how a stream specifies filters.