Redistilling encrypted PDF is not permitted.

[Benn]

> Benn wrote:
>
> >> 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?
>
> AFAIK, this redistilling prevention is unique to Acrrobat /Adobe Reader.
> Other PDF readers, like Mac OS X Preview etc., only check if printing is
> allowed and then generate PostScript as usual, assuming that the PostScript
> job is directed to the printer without further format change.
>
> And yes, the mime type override is included by default in Ubuntu
> distributions.
>
> Helge
>

Well, but if that were the case, then I wouldn't be having this problem. It
works as expected when printing from Adobe Reader. The print job only fails
with that message if it isn't.

As a test, I set up a fresh new Ubuntu CUPS server running the latest
packaged version of CUPS, and it's doing the exact same thing. I also tried
on both Snow Leopard and Mountain Lion. The resulting PostScript files (found
in the print server's spool directory) are here:

https://webdav.bennlinger.com/SL%20Example.ps
https://webdav.bennlinger.com/ML%20Example.ps

Setting CUPS to treat all PostScript like it does Adobe Reader PostScript
allows the job to go through, although this causes issues with unrelated
print jobs and also causes the printer to print (in addition to the
document itself):

ERROR: undefined
OFFENDING COMMAND: eexec

It seems like anyone supporting a large number of Macs with a CUPS server
would run into this issue. I'm not sure why there's not a clear and easy
solution.