Bug 696274

Summary:	Encrypting breaks pdfmarks
Product:	Ghostscript	Reporter:	Hin-Tak Leung <htl10>
Component:	PDF Writer	Assignee:	Ken Sharp <ken.sharp>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P4
Version:	9.16
Hardware:	PC
OS:	Linux
Customer:		Word Size:	---

Description Hin-Tak Leung 2015-10-14 00:34:44 UTC

In preparing the slides for a talk, I had 

-dPermissions=-4096 -dEncryptionR=3 -dKeyLength=128 -sOwnerPassword=x -sUserPassword=y

added to the ps2pdf stage, and found that none of the outline bookmarks works.
Dropping those flags gives the desired result.

Is there any known conflict between outline pdfmark processing and encryption?

I have managed to post-process the non-encrypted pdf with another tool (qpdf) and get the desired outcome, but it seems stupid to add another post-process stage when a few extra options should do it, if they work correctly.

I can supply a trimmed down test file at some stage, if needed.

Comment 1 Ken Sharp 2015-10-14 00:37:10 UTC

(In reply to Hin-Tak Leung from comment #0)

> Is there any known conflict between outline pdfmark processing and
> encryption?
No.

 
> I can supply a trimmed down test file at some stage, if needed.

We always require a test file and a full command line, you should also be testing with the current released version.

Comment 2 Hin-Tak Leung 2015-10-15 19:36:30 UTC

I found my month-old HEAD binary works correctly, and went back through my stash of older snapshot binaries lying around, and located the fix to be between 29cc06b and 9b4c78e - that's about 70 commits between those, happened between april and June, within the last 1/2 year.

I had a vague impression that it was known recent issue when I filed, that's why I asked. There is probably a recent bug report that this can be solved as duplicate, but it is not important now.

looking through the log between 29cc06b and 9b4c78e, I'd guess the fix is this:

commit cb48631e7254e0843a08f075777cbecb43947823
Author: Ken Sharp <ken.sharp@artifex.com>
Date:   Tue Jun 9 09:20:10 2015 +0100

    pdfwrite - write encrypted strings in Dests tree if protected PDF output
    
    Bug #695992
    
    We were forced to stop using names when creatng a Dests tree (instead of
    an array), even though it seems legal, because Acrobat didn't like it.
    
    However, I forgot to take account of password protected PDF files, which
    require us to encrypt strings. Encryption is applied in this commit if
    it is required.

Comment 3 Hin-Tak Leung 2015-10-20 11:56:59 UTC

cb48631e7254e0843a08f075777cbecb43947823 applies cleanly to 9.16, and fixes the issue. FYI, just confirming.