> Date: Mon, 24 Nov 2008 21:58:58 +0100
> From: [EMAIL PROTECTED]
>
> 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.
>
For that very reason and some points I mention below, my suggestion is to delay
the crypt filter implementation until we develop another upper-level encryption
module.
The points are,
1. As read in section 7.6.1 encryption algorithms (8 counting the
public-key one) and encryption filters are complex enough that they
should impose us an upper layer module to deal with them. (keep in
mind that "encryption filter" and "crypt filter" refer to different
things, the former related to file "security handlers")
2. As read in section 7.6.5 crypt filter were introduced to provide
finer granularity control over the PDF document. IMHO that means that
the crypt filters should be implemented upon the assumptions of the
new module suggested in the previous item. But that doesn't mean that
in our architecture the crypt filter should be implemented _on top_
of that new module, i.e. there is a semantic dependency rather than
structural one, this due to the crypt filter concept on itself.
Just an opinion,
-gerel
