[pdftex] Printing problems with \pdfcrypt in pdftex-pretest-1.00a

[Heiko Oberdiek]

On Tue, 21 Aug 2001, Berthold Crysmann wrote:

> I have noticed that pdftex pretest 1.00a produces files that may not
> print on some Unix spool systems (e.g. CUPS with non-ps printer), if the
> \pdfcrypt primitive is used. The reason for the print failure is that
> the PS file generated by AR 4.05 cannot be piped to gs. CUPS (and other
> spool systems), however, pipe to a gs backend on systems without a ps
> printer.
>
> Here's a simple procedure to reproduce the bug:
>
> 1. Generate document with pdfTeX, Version 3.14159-1.00a-pretest-20010806
> and \pdfcrypt noedit in the preamble
> 2. Open in AR4.05 and print to file pdfcrypttest.ps
> 3. Open with ghostscript: `gs pdfcrypttest.ps' should work, `cat
> pdfcrypttest.ps| gs -'  should fail.

The problem is following PostScript code:

currentfile eexec
087329a1c14f91c06b1beed88c3a017a57dc55b72c277c307a6dad3699d3
7e17892296d7d6c6922fa0c5f42f128b79df36afc85b6fdb03e144d6ef74
3ecd328b687f222274a77d79e6c485ff08bdbc5e61ca58e5c125176d5974
d0f16615e05ffaca44ab3a1e4ffb6c21823f8babbdadc183c8217b8b402d
20f939f69910daf2801ce82493f35f170d31fcd898c4fe7cf03596daac2d
55e0f71e44cd5c1f3dc3132f073c6a34973eab3171fb86168707f4e5c16b
e2ad87cdaf9ae7089ff83e958e17d6e20ee05dee82af02015d8cedea1ebb
86284aa7
exec

The code can be decrypted by gs's eexecDecode filter.
The result is correct PostScript code:

/currentdistillerparams where { pop /pdfmark where
{ pop (The owner of this file does not permit its conversion to PDF.)
print quit}if }if
end PDFVars begin PDF begin PDFVars/InitAll get
currentfile closefile |

* The first "end" closes statusdict that is put on
  the dictionary stack by eexec.
* | marks the end of the decrypted code.
The last space ends the name "closefile", the encrypted
part is so finished and the following "exec" will
execute "InitAll", previously pushed on the stack.

I assume, the problem is the detection of the
encrypted text. Perhaps gs reads (buffers) the
next characters and sees "ex", the first letter
is a valid hex letter, but "x" is not. If gs is
not in pipe modus, it can go back before the "e".
But in pipe modus, gs can not go back and throws
the two "wrong hex" letters away probably.
The remaining "ec" results then in an undefined
error message.

Workaround: adding a comment line after the hex code
before "exec". So the end can be more safely detected.
And no problem arises, if the percent char is thrown
away:

...
86284aa7
%
exec

Or in a pipe, it can be automated to add an empty
comment line before each "exec" line:

cat test.ps | perl -p -e 's/^exec$/%\nexec/' | gs -

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