Re: [Printing-architecture] PDF CUPS filter packages

[Till Kamppeter <till.kamppeter@gmail.com>]

Koji Otani wrote:
> This is more complicated. GS doesn't check this, Adobe Reader 8 seems
> to use a trick.
> Following code is embeded in output PS:
> ----------------------
> %ADOBeginClientInjection: DocumentSetup Start "No Re-Distill"
> %% Removing the following eleven lines is illegal, subject to the
> Digital Copyright Act of 1998.
> mark currentfile eexec
> 54dc5232e897cbaaa7584b7da7c23a6c59e7451851159cdbf40334cc2600
> .....
> ----------------------
> 
> So, this will not be a matter of GS.
> 
> ---------------
> Koji Oatni
> 

Below is my talk with Ralph Giles (rillian), leader of Ghostscript (IRC: 
#ghostscript on Freenode) about the problem of DRMes PDF files. WDYT 
should we do?

    Till

---------------------------------------------------------------------

<tkamppeter> rillian, hi
<rillian> hi till. what's up?
<tkamppeter> I have a problem with the PDF printing workflow.
<tkamppeter> I want to do all page processing in a pdftopdf CUPS filter 
instead of pstops, to improve reliability for these operations.
<tkamppeter> So I replace PostScript by PDF as print job format.
<tkamppeter> Now there is the Adobe Reader, closed-source, so cannot be 
patched to output PDF instead of PS when printing.
<rillian> ok...
<tkamppeter> Seems to be no problem for CUPS. CUPS starts with a pstopdf 
filter, based on Ghostscript to get PDF out of the PS coming from Adobe 
Reader
<tkamppeter> works perfectly with unencrypted PDFs.
<tkamppeter> Now I have an encrypted PDF, allowed is only PRINTING the file.
<tkamppeter> In this case the Ghostscript called by the pstopdf filter 
does not convert the file backk to PDF, giving the following error:
<tkamppeter> This PostScript file was created from an encrypted PDF file.
<tkamppeter> Redistilling encrypted PDF is not permitted.
<tkamppeter> ERROR: /undefined in --get--
<rillian> like they say, DRM can't enforce copyright law accurately
<rillian> (although it shouldn't say /undefined in --get--; feel free to 
file a bug on that
<tkamppeter> The error seems to be generated by the following piece of 
code inserted in the PS:
<tkamppeter> %ADOBeginClientInjection: DocumentSetup Start "No Re-Distill"
<tkamppeter> %% Removing the following eleven lines is illegal, subject 
to the
<tkamppeter> Digital Copyright Act of 1998.
<tkamppeter> mark currentfile eexec
<tkamppeter> 54dc5232e897cbaaa7584b7da7c23a6c59e7451851159cdbf40334cc2600
<tkamppeter> .....
<tkamppeter> Something needs to be changed in Ghostscript so that one 
can print this file ...
<rillian> I'm not sure what you want
<rillian> a flag that says "no really, I'm being called as a component 
of a print chain"?
<rillian> can you not just print such files as postscript directly?
<rillian> do you really need to be adding special support for 
proprietary software in the CUPS workflow?
<tkamppeter> I want to replace PostScript by PDF as standard print job 
format, probably you have been on one of my Printing Summits where we 
have talked about that.
<rillian> tkamppeter: I'm aware of that
<tkamppeter> Especially I want to make the page management (N-Up, 
selected pages, booklets, ...) reliably working,
<tkamppeter> but also nice things as smaller jobs, transparency, high 
color depths, ...
<tkamppeter> Now I once let free apps output PDF instead of PostScript 
(this needs only some small bits changed in Qt and GTK)
<rillian> tkamppeter: the document contains code that prevents 
redistillation. I don't think it's our place to help with that.
<tkamppeter> so I need to add an exception to the CUPS workflow for this 
one proprietary app?
<rillian> that's what you're asking for
<rillian> at least, if you want such DRM'd documents to print
<rillian> if it wasn't clear, I sounds like the DRM in question is *in 
the postscript file*
<rillian> it's not ghostscript enforcing it, it's the file itself
<tkamppeter> As if GS would convert it happily back to PDF there would 
be no exception, all jobs run through pdftopdf and no exception in the 
CUPS filtering is needed.
<rillian> so we'd have to actively detect and circumvent the DRM code
<rillian> if it really is just a set of lines, it might be easier to 
have your pstopdf script do that before feeding it to ghostscript
<tkamppeter> Does this DRM code detect whether the output device is 
"pdfwrite" and then stops and otherwise lets the interpreter continue?
<rillian> I don't know how it works
<rillian> can you post the document somewhere?
<rillian> (I expect it's more general that checking for 'pdfwrite' since 
that's ghostscript specific. It probably looks to see if some distiller 
parameters are being respected.)
<tkamppeter> rillian, you mean that the pstopdf script filters out the 
added lines and to make the DRM guys happy to make pstopdf only 
executable by "lp" (the CUPS system user).
* behdad has quit ("Leaving.")
<rillian> tkamppeter: that would make it safer to ship under the DMCA, 
since you could claim it's only used when printing
<rillian> as long as it didn't do anything when the DRM said 'no 
printing' of course...
<tkamppeter> rillian, do you have encrypted PDFs in your regression 
testing repos? Try to convert them to PostScript with the printing 
function of Adobe Reader. Then look into the PostScript code.
<rillian> tkamppeter: personally I wouldn't try to handle this. Tell the 
user their (proprietary) software is adding DRM to the documents it 
prints, which the printing subsystem is not allowed to handle
<tkamppeter> What I can also do with these files is to define a new CUPS 
mime detecting this DRM code and in this case pass it through pstops. 
Assuming that such PostScript comes only from Adobe it will probably 
smoothly do page management with pstops.
* hawk_pdm has quit ("Leaving.")
<tkamppeter> Problem here is that pstops can not be dropped from later 
CUPS releases as long as Adobe does not adopt the PDF printing workflow.
<rillian> or drops their DRM :)
<rillian> but the former is more likely
* KaL_out has quit ("That's not a bug, but a feature")
<tkamppeter> My big problem is that when I switch a distro over to the 
PDF workflow many users will complain that the PDFs which they are 
allowed to print do not print any more.
<tkamppeter> Users will not switch to Linux when they cannot print 
downloaded PDFs which print under Windows.
<rillian> does the file not print from evince?
<tkamppeter> Koji Otani from OpenPrinting Japan has done the tests when 
he was packaging the CUPS filters.
<tkamppeter> rillian, I asked Otani-san now to try to print it from 
Evince. I can imaging that this will work with a later version of 
Evince/GTK which outputs the print data as PDF.
<rillian> it should work, certainly
<rillian> ok, the only restricted pdf I had handy also doesn't allow 
printing, so I don't have the ps output to look at
<rillian> however, evince was happy to print it, so I don't imagine it 
would have qualms about printing a PDF that did allow printing
<rillian> So in addition to my suggestion that you declare this 
Acrobat's problem, I'd offer that there is a work around of not using 
Acrobat