pdfsizeopt icon indicating copy to clipboard operation
pdfsizeopt copied to clipboard

read encrypted and password-protected PDFs

Open pts opened this issue 7 years ago • 1 comments

This is a feature request. Currently pdfsizeopt fails wit the message encrypted PDF input not supported when it encounters an encrypt or password-protected PDF input file. It should be able to decrypt and process it instead (possibly using a password specified in the command-line).

Don't do this, it does too many unwanted and unreliable transformations: gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=unencrypted.pdf -c .setpdfwrite -f encrypted.pdf

Ghostscript has the -sPDFPassword=... flag which may be used, but then we need to apply some tricks (such as pdf2dsc) to read the raw object values and streams.

Some command-lines which avoid unwanted transformations:

  • qpdf --password=YOURPASSWORD-HERE --decrypt input.pdf output.pdf
  • pdftk input.pdf output output.pdf user_pw YOURPASSWORD-HERE
  • pdftk input.pdf output output.pdf user_pw YOURPASSWORD-HERE owner_pw YOURPASSWORD-HERE
  • pdftk input.pdf output output.pdf input_pw YOURPASSWORD-HERE

Adding qpdf to pdfsizeopt_libexec is feasible, it's 1377748 bytes (1.3 MB) when compiled with xstatic g++ -O2.

FYI qpdf generates a random 2nd element of the /ID.

pts avatar Aug 17 '17 12:08 pts

In my experience, I've used gs, qpdf and pdftk to preprocess files to be used with pdfsizeopt. It seems that, as you mentioned, gs does a bit of changes, indeed, on the original file, but it is the only one that works in as many situations as possible.

OTOH, give that it changes the files (and may resample the images, unless using options like -dPDFSETTINGS=/prepress), that is usually my last resort.

From all three, I have had the best luck with qpdf and, sometimes, I even preprocess some files which pdfsizeopt refuses to process (I will send some and/or link them here).

rbrito avatar Aug 24 '17 02:08 rbrito