[pdftex] pdfcrypt

[Ricardo Sanchez Carmenes]

On Thu, 3 Oct 2002, Michael Chapman wrote:

> On Wednesday 02 October 2002 09:12, Martin Schroeder wrote:
> >
> > P.S.: From the NEWS of the next pdfTeX version:
> >       - The extensions for pdf encryption have been removed,
> >         since they make the pdfTeX code overly complex.
>
> Can anyone expand on "complex" ?
>
> 	- makes it larger? Well it would. (But hardly a
> 	   problem these days.)
>
> 	- the crypt part is in itself complicated ?
> 	   Does that matter if it is a switchable option.
>
> 	- there are too many links between the crypt
> 	   part and the 'vanilla' parts, that then makes
> 	   maintaining the 'vanilla' parts difficult?
>
> The last would seem the only logical reason for 'pulling' crypt out of the
> distribution. _But_ I fully accept there may be reasons other than the above
> three, and better analyses than the above.
>
> Whilst his achievement was by no means minor, I did not have the impression
> from Ricardo Cármenes that the third possible reason cited above was his
> difficulty in incorporating crypt. But perhaps he could, himself, comment?

The main difficulty was to reorganise code to ensure that every stream
output is sent at the very last moment through the same routine, and
encrypted or not, depending on the settings. Now that this has been done,
to add enhancements or additions it is only necessary to take care that
the common output routines are used. Not only this is not a difficulty,
from my point a view, but it is a good coding practice that facilitates
code mantainance and enhancement.

One funny thing in this story, is that the encryption routines were
already present in the distributed source tree (although unused). They
come from the xpdf libreary that uses them to view encrypted files.
PDF standard encryption and decryption are symetrical, that is, the same
algorythm and the same routine does the same job (this is clearly stated
in the official Acrobat PDF specs).

With respect to the preference of some to implement the encryption in
postprocessors or filters, as explained in other mails, I have nothing to
argue against. The same approach can be used to generate unencrypted pdf
files from TeX sources (e.g. dvipdf), so someone could argue that pdftex
is unecessary and adds complexity to TeX. Obviously, it is not my idea,
I like pdftex. But I think that several approaches can coexist, and each
one to choose the one that suits him/her better.

The filter approach *is* already available, although it is not freeware.
See my other mail in the list that answers a mail from Thierry Bouche
(I had sent the answer only to him by error, so I resent it to the list
now because it can be of broader interest).

> I do though remember a lot of political noise at the time crypt first
> started. It would be unreasonable to suggest "[makes] the code overly
> complex" is a euphemism for a political decision. But still people might be
> tempted to think along that route ... so basically this is just a plea for
> more information / more discussion.
>
> Thanks,
> 	Michael Chapman
> _______________________________________________
> pdftex mailing list
> pdftex at tug.org
> http://tug.org/mailman/listinfo/pdftex

Regards,
Ricardo.