Bug 696274 - Encrypting breaks pdfmarks
Summary: Encrypting breaks pdfmarks
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: 9.16
Hardware: PC Linux
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-14 00:34 UTC by Hin-Tak Leung
Modified: 2015-10-20 11:56 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.