Redistilling encrypted PDF is not permitted.

Benn benn at linger.com
Mon Feb 11 15:41:06 PST 2013


> Benn wrote:
>
> > I manage a university-wide CUPS & Samba server and an occasional recurring
> > problem is that print jobs will get hung up as:
> >> stopped "/usr/lib/cups/filter/pstopdf failed"
> >
> > After checking the error_log, I find:
> >> This PostScript file was created from an encrypted PDF file.
> >> Redistilling encrypted PDF is not permitted.
> >> %%[ Error: undefined; OffendingCommand: eexec ]%%
> >
> > After checking out the PDFs being printed, I can confirm they have
> > password protections in place to prevent certain actions, but I'm confused
> > as to why it matters. The client was able to print them to the print
> > server, and if the client sends the job straight to the printer, there's
> > no problem. So why is it that this error only occurs when the CUPS server
> > tries to process it?
> >
> > Any idea how I could make it process those jobs normally without throwing
> > that error and stopping the job?
>
> The reason is that an encrypted PDF can be printed (preferably in
> PostScript) but not (possilby modified) converted to PDF again. To achieve
> this, Acrobat (and Adobe Reader) insert PostScript snippets into the
> generated print job that lead to the error you mentioned.
>
> There are two ways to get around this issue:
>
> (1) Revert CUPS to using PostScript as the default print job language and
> install the necessary filters.
>
> (2) Edit your xxx.types and xxx.convs files and set up a document format
> like
> application/vnd.acrobat-postscript
> by specifying the string "Creator: Adobe Acrobat" in the definition of this
> document type, and set up your xxx.convs such that this document type
> bypasses the pstopdf filter and uses only the pstops filter instead.
>
> Helge
>
> PS: bypassing the "redistilling brake" in the PS stream is quite tricky and
> illegal in most countries due to the DRM regulations.
>

After posting this, I looked into the xxx.types and xxx.convs file and found
the override you're describing in 2 (perhaps added by default in some
distributions?). That part seems to be working as intended, too, because
printing any affected PDFs from Adobe Reader works as expected.

However, the issue has been occurring, and I suspect it's because printing
these PDFs from OS X Preview (or possibly other PDF viewers, like Google
Chrome) tags those PDF viewers as the creators instead of Adobe Reader. I
could just tell my users to use Adobe Reader, but I'd rather things "just
work," especially if it's really something the print server should be able
to handle.

Would my cleanest solution be the other option you've selected? Could I just
create a bash script to act as a "custom filter" that just checks for "eexec"
lines in the Postscript and calls the next filter (pstopdf or pstops) based
on whether or not that string is found?




More information about the cups mailing list