Re: [pdf-devel] Crypt filter issue

[Leonard Rosenthol]

Just out of curiously - why are you bloating the size of the PDF by using 
ASCIIHexDecode on these streams?

Leonard


On 11/24/08 9:58 PM, "Jose E. Marchesi" <address@hidden> wrote:



Hi David.

   I am writing crypt filter and it arises a doubt related to
   gnupdf's design. According to PDF Reference, encrpytion is defined
   (mostly) by a global dictionary. This dictionary holds a list of crypt
   filters will
   be used in the rest of the document.

   I suppose crypt filter module will receive parameters from its filter
   dictionary. However, it is not enought, it is even optional. We must
   consider global data, I think. Nevertheless these parameters will be
   known by upper layers.

There is not a 1-1 relationship between any PDF filter and a stm
filter, although it is common. Regardless the origin of the data we
should identify the needed stm filters that will allow us to implement
the processing of the higher-level PDF filters.

An example is the JBIG2 decoder. To describe several "images"
(XObjects) a PDF file can use the following streams:

A stream containing global segments to use with all the images:

10 0 obj
<< /Filter ASCIIHexDecode >>
stream
...
endstream
endobj

and several streams defining the images:

20 0 obj
<< /Filter [/ASCIIHexDecode /JBIG2Decode]
   /DecodeParms [null << /JBIG2Globals 10 0 R >>] >>
stream
...
endstream
endobj

30 0 obj
<< /Filter [/ASCIIHexDecode /JBIG2Decode]
   /DecodeParms [null << /JBIG2Globals 10 0 R >>] >>
stream
...
endstream
endobj

We would use only two stm filters to get the decoded JBIG2 data: one
stm filter per image, using as a parameter for the filters the
contents of the "10 0 R" PDF stream.





--
Leonard Rosenthol
PDF Standards Architect
Adobe Systems Incorporated