From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4848639A.3010100@gmail.com> Date: Fri, 06 Jun 2008 00:07:22 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <484683B0.2060708@gmail.com> <20080605.153828.28801505.sho@bbr.jp> <484794CF.10300@gmail.com> <20080605.193227.233691471.sho@bbr.jp> In-Reply-To: <20080605.193227.233691471.sho@bbr.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] PDF CUPS filter packages List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Koji Otani Cc: toratani.yasumasa@canon.co.jp, printing-architecture@lists.linux-foundation.org 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 --------------------------------------------------------------------- rillian, hi hi till. what's up? I have a problem with the PDF printing workflow. I want to do all page processing in a pdftopdf CUPS filter instead of pstops, to improve reliability for these operations. So I replace PostScript by PDF as print job format. Now there is the Adobe Reader, closed-source, so cannot be patched to output PDF instead of PS when printing. ok... 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 works perfectly with unencrypted PDFs. Now I have an encrypted PDF, allowed is only PRINTING the file. In this case the Ghostscript called by the pstopdf filter does not convert the file backk to PDF, giving the following error: This PostScript file was created from an encrypted PDF file. Redistilling encrypted PDF is not permitted. ERROR: /undefined in --get-- like they say, DRM can't enforce copyright law accurately (although it shouldn't say /undefined in --get--; feel free to file a bug on that The error seems to be generated by the following piece of code inserted in the 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 ..... Something needs to be changed in Ghostscript so that one can print this file ... I'm not sure what you want a flag that says "no really, I'm being called as a component of a print chain"? can you not just print such files as postscript directly? do you really need to be adding special support for proprietary software in the CUPS workflow? 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. tkamppeter: I'm aware of that Especially I want to make the page management (N-Up, selected pages, booklets, ...) reliably working, but also nice things as smaller jobs, transparency, high color depths, ... Now I once let free apps output PDF instead of PostScript (this needs only some small bits changed in Qt and GTK) tkamppeter: the document contains code that prevents redistillation. I don't think it's our place to help with that. so I need to add an exception to the CUPS workflow for this one proprietary app? that's what you're asking for at least, if you want such DRM'd documents to print if it wasn't clear, I sounds like the DRM in question is *in the postscript file* it's not ghostscript enforcing it, it's the file itself 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. so we'd have to actively detect and circumvent the DRM code 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 Does this DRM code detect whether the output device is "pdfwrite" and then stops and otherwise lets the interpreter continue? I don't know how it works can you post the document somewhere? (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.) 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.") tkamppeter: that would make it safer to ship under the DMCA, since you could claim it's only used when printing as long as it didn't do anything when the DRM said 'no printing' of course... 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. 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 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.") Problem here is that pstops can not be dropped from later CUPS releases as long as Adobe does not adopt the PDF printing workflow. or drops their DRM :) but the former is more likely * KaL_out has quit ("That's not a bug, but a feature") 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. Users will not switch to Linux when they cannot print downloaded PDFs which print under Windows. does the file not print from evince? Koji Otani from OpenPrinting Japan has done the tests when he was packaging the CUPS filters. 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. it should work, certainly ok, the only restricted pdf I had handy also doesn't allow printing, so I don't have the ps output to look at however, evince was happy to print it, so I don't imagine it would have qualms about printing a PDF that did allow printing 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