[pdftex] Usage of \pdfcrypt

[Heiko Oberdiek]

On Wed, 22 Aug 2001, Hans Hagen wrote:

> At 10:26 AM 8/22/2001 +0900, Akira Kakuto wrote:
>
> >    \pdfcrypt parameter         meaning
> >    --------------------------  ----------------------------------------
> >    owner {the owner password}  to define the owner or security password
> >
> >    user {the user password}    to define the user or open password
> >
> >    print                       to give printing permission
> >    copy                        to allow selecting text and graphics
> >    edit                        to allow modifing (edit) the document
> >    annotate                    to allow changing notes and form fields
> >    all                         to allow all above
> >
> >    noprint                     to deny printing permission
> >    nocopy                      to deny text and graphics selection
> >    noedit                      to deny document modification
> >    noannotate                  to deny changing notes and form fields
> >    none                        to deny all above
>
> Does these flags play a role in calculations? If not, I suggest that they
> are replaced by a
>
>    attr {...}
>
> k/v pair, since this is extensible without the need to change the program.

The other occurences of attr (\pdfobj, ...) are passed through
pdfTeX in the PDF source directly, but the flags of pdfcrypt
have to be interpreted by pdfTeX (they play a role in calculation).
Therefore an attr syntax here means only additional work of writing
a k/v parser for pdfTeX.

> This would also conform to other low level pdf primitives. Since most users
> use a higher level macro package, calculating the flags is no problem. The
> less hard coded keywords, the better. Also, this approach would permit
> additional entries in the associated dict.

The code per flag is one line in C:
  pdfcryptpermit |= 0x0004; /* do Print */
  ...
  pdfcryptpermit &= 0xffec; /* no Copy */
  ...
Of course it can be written in TeX.
Cons:
* TeX does not support the | and & operators of C
  directly. So the TeX code would be much larger
  and the probability for errors rises.
* Bad design, if low level calculation stuff is parted
  between code in pdfTeX and code at TeX level.

Yours sincerely
  Heiko <oberdiek at uni-freiburg.de>