Redistilling encrypted PDF is not permitted.

[Helge Blischke]

Benn wrote:

>> 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.

Well, obviously I'm wrong with Preview.
But anyway, the issue is only raised if and only if the generated PostScript 
is again converted to a PDF file, as increasingly done by most Linux 
distributors as they adopt the OpenPrinting attitude to switch to PDF as the 
internal document format for printing.
Thus, the only way to avoid this issue is to revert to the PostScript 
oriented workflow in CUPS as it was before Apple decided to hand ober the 
maintenance and developement of the filters not used in Mac OS X to 
OpenPrinting.org.

By the way, when decrypting the eexec stuff from your sample files reads as 
follows:

/currentdistillerparams where { pop /pdfmark where^M{pop (This PostScript 
file was created from an encrypted PDF file.\n) print^M(Redistilling 
encrypted PDF is not permitted.\n) print^Muserdict /quit get exec }if} if 
end cg_md begin systemdict begin^Mcurrentfile closefile^M

Helge

PS: an additional way to solve this issue would be to call Ghostscript 
(which usually is used to generate PDF from PS input) with the additional 
command line option -dWRITESYSTEMDICT and prepending a PS snippet to the 
input PS file containing in essence the statement
systemdict /currentdistillerparams undef

But note that I didn't test this so far.