Re: PDF Encryption in HEAD
Ok, now I'm a bit smarter. It took me pretty long to realize what was really wrong that I got blank pages. The real reason was that if you don't have any filters active that have a name Acrobat Reader has problems if the stream is encrypted. As soon as you add the Flate filter, for example, the page is displayed. So what Jörg told me was already one step further down the road. I wasn't there at that time. Now I also understand what you are discussing. After poking around the code I realized I don't like the way filters are realized at all. The content of the StreamCache instances gets abused. First you fill in the raw contents, then apply the filters. The result gets stored in the place of the raw contents. If you don't object I will rework the filter stuff so the filters get applied later, namely when it's time to serialize to the OutputStream. The encoding will be reworked from encode(in, out) calls to a chain out FilterOutputStream descendant (as done for the PostScript renderer). That should also reduce the number of buffer reallocations a bit and improve performance because the buffers don't get copied around so many times. Or so I hope. If nothing else it should clean up the design and make it easier to apply filters/encryption in a more uniform way. The code is currently scattered all around the package and in the PDF renderer package. While doing the above work I also realized that the font support was more or less broken. I've fixed it along the way as good as it went. I'll add the changes soon. But now I have to atend to other duties first. See ya. On 14.03.2003 00:00:37 Keiron Liddle wrote: > > That's why I didn't commit the patch: I didn't want to re-add > > the PDFDocument reference to PDFXObject in order to get the > > add the encryption filter after the makeStream() without asking > > why the reference had been dropped on the way from maintenance > > to HEAD. > > The PDFDocument was used in the constructor to create ICCStreams for jpeg > images. This seemed all to specific and was moved to the setup for the > FopPDFImage. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Yes, redesign happens in HEAD. Thanks. I'll be after it, too, today. On 14.03.2003 03:14:31 Patrick C. Lankswert wrote: > Be more than happy to look at it. Did you commit to HEAD or else where? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
many thanks I will try Bernard > -Original Message- > From: J.Pietschmann [mailto:[EMAIL PROTECTED] > Sent: 13 March, 2003 22:57 > To: [EMAIL PROTECTED] > Subject: Re: PDF Encryption in HEAD > > > Bernard D'Have wrote: > > Can you port your change to the maintenance branch? > > I'm very interested to have encryption with JDK1.3. > > Well, now build support depends on JCE rather than the JDK 1.4 > presence check. > > J.Pietschmann > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
Jeremias, Be more than happy to look at it. Did you commit to HEAD or else where? Pat -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 12:00 PM To: [EMAIL PROTECTED] Subject: Re: PDF Encryption in HEAD Hi crypto-guys! I've just committed PDF encryption support by Patrick C. Lankswert to the redesign. The bad message is that it doesn't work yet. I get blank pages in Acrobat when enabled, although the PDF looks good when compared with one generated by the maintenance branch. I guess that's the same problem you had, Jörg? Well, and I haven't enabled encryption everywhere, yet. That shouldn't be a problem right now, because I've extended the stuff to be completely optional depending on the availability of JCE and/or cryptographic algorithms necessary. No need for java-1.3/java-1.4 directories, which is actually strange if you have JCE installed on JDK 1.3. The stuff looks out for "javax.crypto.Cipher" to be present to determine if JCE is available. A seperate check looks for the necessary algorithms (RC4 and MD5). My stuff is configured via the FOUserAgent which can now hold a PDFEncryptionParams object containing the passwords and permissions. If is null (default) no encryption happens. I thought I just commit my stuff and we'll figure out what's wrong based on that code. Better this than nothing. I'll continue my investigations tomorrow. Maybe Patrick could have a look at the stuff. Maybe you finds something? On 09.03.2003 23:44:27 J.Pietschmann wrote: > Hi all, > I tried to get PDF encryption into HEAD and failed. > Most of the problem is that PDFXObject no longer has a reference > to the PDFDocument, where the encryption object resides in the patch. > I'm not sure how important this is, the encryption filter is > different from the other filters: it takes the number+generation > of something, however, at some instances it takes the number+gen > from the XObject, at others (ICCStream) from the stream it is > applied. I have not enough knowledge of PDF encryption to sort > this out. Actually, I didn't try the code from the maintentance > branch with an image (hint, hint: need GIF/BMP, JPG with ICC and > EPS to test. Jeremias: this appears to be your speciality...). > > Any hints how to proceed? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
Clay, Ooops... sorry, you asked about command line. J, Thanks for all your help pulling this together. Pat -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 3:10 PM To: [EMAIL PROTECTED] Subject: Re: PDF Encryption in HEAD Clay Leeds wrote: > I'd be interested > in finding out how to run these encryption (?) options running FOP from > the command line. The easiest way you can imagine: 1. get the latest CVS maintenance branch code (it's not in 0.20.5rc2) 2. build 3. run fop.sh/fop.bat without parameters. Also, the docs are already online (a bit prematurely) http://xml.apache.org/fop/running.html http://xml.apache.org/fop/pdfencryption.html J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
Clay, Right now the options are pass the the render. Examples can be found in the command line implementation. But to save you some time, the rendor options are pass as a hash map (name value pairs) to the render. If any encryption options are passed, encryption is enabled. The value names are as follows: ownerPassword userPassword allowPrint allowCopyContent allowEditContent allowEditAnnotations The last four are either TRUE or FALSE. The default is TRUE. Pat -Original Message- From: Clay Leeds [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 10:41 AM To: [EMAIL PROTECTED] Subject: Re: PDF Encryption in HEAD I too am interested in how this would be implemented, particularly in enabling some of the PDF features such as "don't print me" and "don't save me" and "don't copy me" (where the "print", "save" and "copy" functions are inactive/grayed out) using the command line version. I use either the .sh or .bat file to render on *nix & Win*. I'd be interested in finding out how to run these encryption (?) options running FOP from the command line. Web Maestro Clay Manuel Mall wrote: > Patrick, > > I am following with much interest the integration of PDF encryption into > FOP. > > While trying to understand how it is invoked (not configured) I got > confused. We currently using a 3rd party external tool to encrypt our PDFs > after creation through FOP. Each PDF is given its own different owner > password. Internally we have one instance of FOP Driver in our server which > we call again and again to render the PDFs on demand. If we want to use the > encryption within FOP we would need to be able to set the owner password > before each individual run. Is that possible? With the current FOP version > (Maintenance branch) the concurrency issues within FOP are suppose to be > resolved. If that is so we could have pool of Driver instances running in > parallel each needing its own different owner password again on a per run > basis. Is that supported? > > Many thanks > > Manuel -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
Manual, I think so... the encryption objects are associated with the PDF Document so as long as there is only on thread in a given PDF document instance, you should be good to go. Pat -Original Message- From: Manuel Mall [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 4:57 AM To: '[EMAIL PROTECTED]' Subject: RE: PDF Encryption in HEAD Patrick, I am following with much interest the integration of PDF encryption into FOP. While trying to understand how it is invoked (not configured) I got confused. We currently using a 3rd party external tool to encrypt our PDFs after creation through FOP. Each PDF is given its own different owner password. Internally we have one instance of FOP Driver in our server which we call again and again to render the PDFs on demand. If we want to use the encryption within FOP we would need to be able to set the owner password before each individual run. Is that possible? With the current FOP version (Maintenance branch) the concurrency issues within FOP are suppose to be resolved. If that is so we could have pool of Driver instances running in parallel each needing its own different owner password again on a per run basis. Is that supported? Many thanks Manuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
> That's why I didn't commit the patch: I didn't want to re-add > the PDFDocument reference to PDFXObject in order to get the > add the encryption filter after the makeStream() without asking > why the reference had been dropped on the way from maintenance > to HEAD. The PDFDocument was used in the constructor to create ICCStreams for jpeg images. This seemed all to specific and was moved to the setup for the FopPDFImage. > J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
> Ok, runs ok with all images, except EPS (don't have a PS printer to test). Has anyone verified that the EPS in the redesign works? I couldn't get it to show up in xpdf (is that the one that supports it) and never tried on a printer. > The other possibly untested case is th ICCProfile: does the logo.jgp have > this? Any other example? IIRC non of the examples there have an ICCProfile, there is/was one in bugzilla, bigTree.jpg I think. It would be a handy addition to have a smaller example available for future testing if anyone can create such an example. > I alos found a potential problem: all encryption options can be set > multiple times. Should I suppress this? I'm not sure which decision > fits user expectations best: > - accept two owner passwords (and use the last), > - raise an error and abort or > - raise a warning and use the first. Maybe this one, there are probably some java security considerations also in this area. > Any suggestions? > > J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Clay Leeds wrote: all encryption options can be set multiple times. ... Whatever you do, can you have FOP indicate which it has done? (i.e., if you choose the first, output: Good idea! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
J.Pietschmann wrote: I alos found a potential problem: all encryption options can be set multiple times. Should I suppress this? I'm not sure which decision fits user expectations best: - accept two owner passwords (and use the last), - raise an error and abort or - raise a warning and use the first. Any suggestions? J.Pietschmann Whatever you do, can you have FOP indicate which it has done? (i.e., if you choose the first, output: [Warning] Multiple owner passwords, using first. or [Warning] Multiple owner passwords, using first "secret". or something. -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Keiron Liddle wrote: Try the example in test/resources/fop/image/types.fo this has various image formats. Ok, runs ok with all images, except EPS (don't have a PS printer to test). The other possibly untested case is th ICCProfile: does the logo.jgp have this? Any other example? I alos found a potential problem: all encryption options can be set multiple times. Should I suppress this? I'm not sure which decision fits user expectations best: - accept two owner passwords (and use the last), - raise an error and abort or - raise a warning and use the first. Any suggestions? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Bernard D'Have wrote: Can you port your change to the maintenance branch? I'm very interested to have encryption with JDK1.3. Well, now build support depends on JCE rather than the JDK 1.4 presence check. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
Yes I understand Will try Bernard > -Original Message- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > Sent: 13 March, 2003 22:00 > To: [EMAIL PROTECTED] > Subject: Re: PDF Encryption in HEAD > > > Wanna do it yourself and send a patch? I want to invest my resources > into the redesign. I hope you understand. > > On 13.03.2003 21:30:30 Bernard D'Have wrote: > > Can you port your change to the maintenance branch? > > I'm very interested to have encryption with JDK1.3. > > > Jeremias Maerki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Bernard D'Have wrote: Can you port your change to the maintenance branch? I'm very interested to have encryption with JDK1.3. You only have to compile with 1.4 currently, it will run with 1.3 too as long as a JCE impl is in the classpath. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Thanks for the pointer. I hope I can come up with something useful tomorrow. On 13.03.2003 21:02:57 J.Pietschmann wrote: > Jeremias Maerki wrote: > > I've just committed PDF encryption support by Patrick C. Lankswert to > > the redesign. The bad message is that it doesn't work yet. I get blank > > pages in Acrobat when enabled, although the PDF looks good when compared > > with one generated by the maintenance branch. I guess that's the same > > problem you had, Jörg? > > On closer inspection this seems to be the problem: you got > number+generation from the stream into the filter for *every* > XObject, but the original patch used number/gen from the XObject > for all objects except image pixel streams and the JPG ICC > stream. > > That's why I didn't commit the patch: I didn't want to re-add > the PDFDocument reference to PDFXObject in order to get the > add the encryption filter after the makeStream() without asking > why the reference had been dropped on the way from maintenance > to HEAD. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Wanna do it yourself and send a patch? I want to invest my resources into the redesign. I hope you understand. On 13.03.2003 21:30:30 Bernard D'Have wrote: > Can you port your change to the maintenance branch? > I'm very interested to have encryption with JDK1.3. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
Can you port your change to the maintenance branch? I'm very interested to have encryption with JDK1.3. Many thanks, Bernard > -Original Message- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > Sent: 13 March, 2003 18:00 > To: [EMAIL PROTECTED] > Subject: Re: PDF Encryption in HEAD > > > Hi crypto-guys! > > I've just committed PDF encryption support by Patrick C. Lankswert to > the redesign. The bad message is that it doesn't work yet. I get blank > pages in Acrobat when enabled, although the PDF looks good when compared > with one generated by the maintenance branch. I guess that's the same > problem you had, Jörg? Well, and I haven't enabled encryption everywhere, > yet. That shouldn't be a problem right now, because I've extended the > stuff to be completely optional depending on the availability of JCE > and/or cryptographic algorithms necessary. No need for java-1.3/java-1.4 > directories, which is actually strange if you have JCE installed on JDK > 1.3. The stuff looks out for "javax.crypto.Cipher" to be present to > determine if JCE is available. A seperate check looks for the necessary > algorithms (RC4 and MD5). > > My stuff is configured via the FOUserAgent which can now hold a > PDFEncryptionParams object containing the passwords and permissions. If > is null (default) no encryption happens. > > I thought I just commit my stuff and we'll figure out what's wrong based > on that code. Better this than nothing. I'll continue my investigations > tomorrow. Maybe Patrick could have a look at the stuff. Maybe you finds > something? > > On 09.03.2003 23:44:27 J.Pietschmann wrote: > > Hi all, > > I tried to get PDF encryption into HEAD and failed. > > Most of the problem is that PDFXObject no longer has a reference > > to the PDFDocument, where the encryption object resides in the patch. > > I'm not sure how important this is, the encryption filter is > > different from the other filters: it takes the number+generation > > of something, however, at some instances it takes the number+gen > > from the XObject, at others (ICCStream) from the stream it is > > applied. I have not enough knowledge of PDF encryption to sort > > this out. Actually, I didn't try the code from the maintentance > > branch with an image (hint, hint: need GIF/BMP, JPG with ICC and > > EPS to test. Jeremias: this appears to be your speciality...). > > > > Any hints how to proceed? > > > Jeremias Maerki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Jeremias Maerki wrote: I've just committed PDF encryption support by Patrick C. Lankswert to the redesign. The bad message is that it doesn't work yet. I get blank pages in Acrobat when enabled, although the PDF looks good when compared with one generated by the maintenance branch. I guess that's the same problem you had, Jörg? On closer inspection this seems to be the problem: you got number+generation from the stream into the filter for *every* XObject, but the original patch used number/gen from the XObject for all objects except image pixel streams and the JPG ICC stream. That's why I didn't commit the patch: I didn't want to re-add the PDFDocument reference to PDFXObject in order to get the add the encryption filter after the makeStream() without asking why the reference had been dropped on the way from maintenance to HEAD. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Hi crypto-guys! I've just committed PDF encryption support by Patrick C. Lankswert to the redesign. The bad message is that it doesn't work yet. I get blank pages in Acrobat when enabled, although the PDF looks good when compared with one generated by the maintenance branch. I guess that's the same problem you had, Jörg? Well, and I haven't enabled encryption everywhere, yet. That shouldn't be a problem right now, because I've extended the stuff to be completely optional depending on the availability of JCE and/or cryptographic algorithms necessary. No need for java-1.3/java-1.4 directories, which is actually strange if you have JCE installed on JDK 1.3. The stuff looks out for "javax.crypto.Cipher" to be present to determine if JCE is available. A seperate check looks for the necessary algorithms (RC4 and MD5). My stuff is configured via the FOUserAgent which can now hold a PDFEncryptionParams object containing the passwords and permissions. If is null (default) no encryption happens. I thought I just commit my stuff and we'll figure out what's wrong based on that code. Better this than nothing. I'll continue my investigations tomorrow. Maybe Patrick could have a look at the stuff. Maybe you finds something? On 09.03.2003 23:44:27 J.Pietschmann wrote: > Hi all, > I tried to get PDF encryption into HEAD and failed. > Most of the problem is that PDFXObject no longer has a reference > to the PDFDocument, where the encryption object resides in the patch. > I'm not sure how important this is, the encryption filter is > different from the other filters: it takes the number+generation > of something, however, at some instances it takes the number+gen > from the XObject, at others (ICCStream) from the stream it is > applied. I have not enough knowledge of PDF encryption to sort > this out. Actually, I didn't try the code from the maintentance > branch with an image (hint, hint: need GIF/BMP, JPG with ICC and > EPS to test. Jeremias: this appears to be your speciality...). > > Any hints how to proceed? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Manuel Mall wrote:
If we want to use the
encryption within FOP we would need to be able to set the owner password
before each individual run. Is that possible?
Roughly like
Renderer renderer=new PDFRenderer();
HashMap options = new HashMap();
options.put("ownerPassword","secret");
renderer.setOptions(options);
Driver driver = new Driver(
new InputSource(new FileInputStream("foo.fo")),
httpres.getOutputStream());
driver.setRenderer(renderer);
driver.run();
(Untested, beware)
Youcan find the options names in CommandLineOptions.java in the source
distribution.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
Clay Leeds wrote: I'd be interested in finding out how to run these encryption (?) options running FOP from the command line. The easiest way you can imagine: 1. get the latest CVS maintenance branch code (it's not in 0.20.5rc2) 2. build 3. run fop.sh/fop.bat without parameters. Also, the docs are already online (a bit prematurely) http://xml.apache.org/fop/running.html http://xml.apache.org/fop/pdfencryption.html J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
I too am interested in how this would be implemented, particularly in enabling some of the PDF features such as "don't print me" and "don't save me" and "don't copy me" (where the "print", "save" and "copy" functions are inactive/grayed out) using the command line version. I use either the .sh or .bat file to render on *nix & Win*. I'd be interested in finding out how to run these encryption (?) options running FOP from the command line. Web Maestro Clay Manuel Mall wrote: Patrick, I am following with much interest the integration of PDF encryption into FOP. While trying to understand how it is invoked (not configured) I got confused. We currently using a 3rd party external tool to encrypt our PDFs after creation through FOP. Each PDF is given its own different owner password. Internally we have one instance of FOP Driver in our server which we call again and again to render the PDFs on demand. If we want to use the encryption within FOP we would need to be able to set the owner password before each individual run. Is that possible? With the current FOP version (Maintenance branch) the concurrency issues within FOP are suppose to be resolved. If that is so we could have pool of Driver instances running in parallel each needing its own different owner password again on a per run basis. Is that supported? Many thanks Manuel -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
Patrick, I am following with much interest the integration of PDF encryption into FOP. While trying to understand how it is invoked (not configured) I got confused. We currently using a 3rd party external tool to encrypt our PDFs after creation through FOP. Each PDF is given its own different owner password. Internally we have one instance of FOP Driver in our server which we call again and again to render the PDFs on demand. If we want to use the encryption within FOP we would need to be able to set the owner password before each individual run. Is that possible? With the current FOP version (Maintenance branch) the concurrency issues within FOP are suppose to be resolved. If that is so we could have pool of Driver instances running in parallel each needing its own different owner password again on a per run basis. Is that supported? Many thanks Manuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
Great! Thanks. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 8:49 PM To: [EMAIL PROTECTED] Subject: RE: PDF Encryption in HEAD > The encryption filter uses the number and generation as part of the hash to > generate the key for a given object. In short, the encryption key is > different for every object and is based on the number and generation of the > object. I would have preferred something simpler but the PDFXObject is not > what is streamed. It was the PDFICCStream which does not have the number and > generation properly set. > > If someone has a suitable example with the various image formats, I will > test, verify and correct an issues. Try the example in test/resources/fop/image/types.fo this has various image formats. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
> The encryption filter uses the number and generation as part of the hash to > generate the key for a given object. In short, the encryption key is > different for every object and is based on the number and generation of the > object. I would have preferred something simpler but the PDFXObject is not > what is streamed. It was the PDFICCStream which does not have the number and > generation properly set. > > If someone has a suitable example with the various image formats, I will > test, verify and correct an issues. Try the example in test/resources/fop/image/types.fo this has various image formats. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
The encryption filter uses the number and generation as part of the hash to generate the key for a given object. In short, the encryption key is different for every object and is based on the number and generation of the object. I would have preferred something simpler but the PDFXObject is not what is streamed. It was the PDFICCStream which does not have the number and generation properly set. If someone has a suitable example with the various image formats, I will test, verify and correct an issues. Pat -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Sunday, March 09, 2003 5:44 PM To: [EMAIL PROTECTED] Subject: PDF Encryption in HEAD Hi all, I tried to get PDF encryption into HEAD and failed. Most of the problem is that PDFXObject no longer has a reference to the PDFDocument, where the encryption object resides in the patch. I'm not sure how important this is, the encryption filter is different from the other filters: it takes the number+generation of something, however, at some instances it takes the number+gen from the XObject, at others (ICCStream) from the stream it is applied. I have not enough knowledge of PDF encryption to sort this out. Actually, I didn't try the code from the maintentance branch with an image (hint, hint: need GIF/BMP, JPG with ICC and EPS to test. Jeremias: this appears to be your speciality...). Any hints how to proceed? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
I'll have a look at it (Tuesday or Wednesday). On 09.03.2003 23:44:27 J.Pietschmann wrote: > I tried to get PDF encryption into HEAD and failed. > Most of the problem is that PDFXObject no longer has a reference > to the PDFDocument, where the encryption object resides in the patch. > I'm not sure how important this is, the encryption filter is > different from the other filters: it takes the number+generation > of something, however, at some instances it takes the number+gen > from the XObject, at others (ICCStream) from the stream it is > applied. I have not enough knowledge of PDF encryption to sort > this out. Actually, I didn't try the code from the maintentance > branch with an image (hint, hint: need GIF/BMP, JPG with ICC and > EPS to test. Jeremias: this appears to be your speciality...). > > Any hints how to proceed? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
