DO NOT REPLY [Bug 31039] - URL in basic-link is scrambled by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31039>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31039 URL in basic-link is scrambled by encryption --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 13:58 --- Created an attachment (id=12632) example pdf with printing disabled (link doesn't work)
DO NOT REPLY [Bug 31039] - URL in basic-link is scrambled by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31039>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31039 URL in basic-link is scrambled by encryption --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 13:57 --- Created an attachment (id=12631) example pdf with no encryption (link works)
DO NOT REPLY [Bug 31039] - URL in basic-link is scrambled by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31039>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31039 URL in basic-link is scrambled by encryption --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 13:56 --- Created an attachment (id=12630) example xsl
DO NOT REPLY [Bug 31039] - URL in basic-link is scrambled by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31039>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31039 URL in basic-link is scrambled by encryption --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 13:56 --- Created an attachment (id=12629) example xml
DO NOT REPLY [Bug 31039] New: - URL in basic-link is scrambled by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31039>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31039 URL in basic-link is scrambled by encryption Summary: URL in basic-link is scrambled by encryption Product: Fop Version: 0.20.5 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I process a document with a tag sometext the link in the resulting pdf points to something that I presume is the *encrypted* URL. This of course doesn't work. I am using JDK 1.4.2 on linux and the Bouncy Castle crypto provider version 1.24.
DO NOT REPLY [Bug 21303] - Embeded Fonts and signets disturbed by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=21303>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=21303 Embeded Fonts and signets disturbed by encryption [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows NT/2K |All Platform|PC |All --- Additional Comments From [EMAIL PROTECTED] 2004-06-22 18:28 --- Please realize that the bug won't be fixed for FOP 0.20.5 as this line of development is frozen in favor of the main development direction (CVS HEAD) where the bug is already fixed. You've seen the work-around I posted in an earlier entry for this bug, haven't you?
DO NOT REPLY [Bug 21303] - Embeded Fonts and signets disturbed by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=21303>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=21303 Embeded Fonts and signets disturbed by encryption --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 08:20 --- this not only appears unter windows (also my windows fop-version (0.20.5) ignores the -nocopy, -noedit, -o flags). this also is true for the linux version. it is very anoying. markus
DO NOT REPLY [Bug 26589] - AIX 5.2, ibm jdk 1.4.0, OutOfMemoryError with PDF Encryption only
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26589>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26589 AIX 5.2, ibm jdk 1.4.0, OutOfMemoryError with PDF Encryption only [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 20:25 --- Unfortunately, we can't take responsiblity for memory leaks in the vendor's JRE. Please report this to IBM.
DO NOT REPLY [Bug 26589] New: - AIX 5.2, ibm jdk 1.4.0, OutOfMemoryError with PDF Encryption only
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26589>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26589
AIX 5.2, ibm jdk 1.4.0, OutOfMemoryError with PDF Encryption only
Summary: AIX 5.2, ibm jdk 1.4.0, OutOfMemoryError with PDF
Encryption only
Product: Fop
Version: 0.20.5
Platform: Other
OS/Version: AIX
Status: NEW
Severity: Critical
Priority: Other
Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi,
I am currently writing a XML-PDF Converter.
The input is a xml & xsl file and the output is a pdf file.
We develop it on SunOS 5.8, it works without problems, without and also with
PDF Encryption (we produce e.g. 200 000 PDFs).
However, when we port it to the AIX environment, it runs successfully only
without PDF encryption.
With PDF Encryption our program throws the "java.lang.OutOfMemoryError:
ZIP002:OutOfMemoryError, MEM_ERROR in deflate_init2" after while (e.g. 7 000
PDFs).
Details:
- the error is reproducable (input file e.g. 35 kB, program crash always after
7 112 input files)
- the memory demand increases and increases till JVM dies (only on AIX)
Environment:
- OK Tests on SunOS 5.8 with Java HotSpot(TM) Server VM (build 1.4.1_02-b06,
mixed mode)
- OutOfMemoryError on AIX 5.2 with Classic VM (build 1.4.0, J2RE 1.4.0 IBM AIX
build ca1401-20021126 (JIT enabled: jitc))
I repeat - without PDF Encryption works it good also on AIX!
Conclusion:
- Memory leaks lay in combination of ibm jdk 1.4.0 on AIX machine and FOP
0.20.5 with PDFEncryption (probability 95%)
Do you have any comment?
Thanks in advance.
Regards,
Richard Sysala
DO NOT REPLY [Bug 21303] - Embeded Fonts and signets disturbed by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21303>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21303 Embeded Fonts and signets disturbed by encryption --- Additional Comments From [EMAIL PROTECTED] 2003-12-01 20:28 --- Not anytime soon, I'm afraid. Actually, the problem is fixed in our main development tree (aka redesign), though that won't help you much until the that code is ready for a release. And that will still take some time. As a workaround you can use a third-party tool to encrypt the PDFs.
DO NOT REPLY [Bug 21303] - Embeded Fonts and signets disturbed by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21303>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21303 Embeded Fonts and signets disturbed by encryption --- Additional Comments From [EMAIL PROTECTED] 2003-12-01 19:18 --- Can anyone please tell me as to when this will be fixed?? Thanks in advance. Beena
DO NOT REPLY [Bug 21303] New: - Embeded Fonts and signets disturbed by encryption
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21303>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21303 Embeded Fonts and signets disturbed by encryption Summary: Embeded Fonts and signets disturbed by encryption Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using FOP 0.20.5RC3a with JDK1.4.0 and bcprov-jdk14-119.jar for Encryption. I have FO doc including Batang font and Signets ( tags). Works well without protections. But with '-o' or '-noread', Signets are coded (not readable), and Font is not retreived. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20480] - PDF outline texts are garbled when PDF encryption is activated.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20480>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20480 PDF outline texts are garbled when PDF encryption is activated. --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 14:52 --- The reason for the garbled text is the lack of encryption on string objects as they occur in outline objects in PDF. In HEAD it took quite a bit of refactoring to get it right. If someone wants to fix it you can look at PDFObject.encodeText() and PDFOutline.toPDF() in HEAD for reference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20480] - PDF outline texts are garbled when PDF encryption is activated.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20480>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20480 PDF outline texts are garbled when PDF encryption is activated. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|NEW |ASSIGNED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20480] New: - PDF outline texts are garbled when PDF encryption is activated.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20480>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20480 PDF outline texts are garbled when PDF encryption is activated. Summary: PDF outline texts are garbled when PDF encryption is activated. Product: Fop Version: 0.20.5 Platform: All URL: http://marc.theaimsgroup.com/?l=fop- user&m=105463470502180&w=2 OS/Version: All Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The effect can be seen with examples/fo/basic/pdfoutline.fo. As soon as PDF encryption is activated the texts in the outline are garbled. Redesign/HEAD works, only maintenance branch is affected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)
Jeremias Maerki wrote: +1 for a 0.20.5rc3 ASAP (as Clay Leeds suggests). 0.20.5rc2 is bugged and I believe Jörg is tired of marking new bug reports as duplicates. :-) +1 for really (!) going to bugfixing-only mode in the maintenance branch. +1 for 0.20.5 being the last release from the maintenance branch. ditto. -- Oleg Tkachenko http://www.tkachenko.com/blog Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)
+1 for a 0.20.5rc3 ASAP (as Clay Leeds suggests). 0.20.5rc2 is bugged and I believe Jörg is tired of marking new bug reports as duplicates. :-) +1 for really (!) going to bugfixing-only mode in the maintenance branch. +1 for 0.20.5 being the last release from the maintenance branch. But being realistic, -0 on new bugfix release(s) if needed. Bugfixing only!!! 0.20.5a, 0.20.5b..., no 0.20.6. +1 for somebody providing funds so I can stay "unemployed" a little longer and invest more time in the redesign. I've got to get some money coming in again in about three months from now. The sooner the better. +1 for FOP enthusiasts start helping with the redesign. +1 for banning all lawyers to a small isolated pacific island. No seriously, I have one test case of grant submission running for over two weeks now. I haven't gotten any confirmation on that, yet. Ok, I was also shoving that before me, but I'm going to check on the status today. I promise. Once, I get the first through, I'll start the others. On 02.04.2003 16:22:11 Christian Geisert wrote: > J.Pietschmann wrote: > > [..] > > > Because hyphenation license updates seem to be slow, what about > > doing an rc3 in 10-15 days? We'll get rid of this duplicated text > > problem which poeple complain about much too often and get also > > a more thourough test of the encryption stuff. > > Yes, another RC makes sense but I'm a bit unsure about the > timeframe because I'd like 0.20.5rc3 to be the last RC before > releasing 0.20.5 (i.e at best no changes after rc3) but there > is still the issue with the hyphenation patterns which will > probably take some to be solved as we we shouldn't use LPPL > stuff (did I understand this right?) > > So what about rc3 in two weeks and then really stop with the > maintenance branch? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)
Forgive my ignorance, but can someone explain the argument for limiting the number of Release Candidates? If testing needs to be done, why not create snapshots that could be used for testing more widely. Since I don't currently use hyphenation, I don't want to wait for the hyphenation patterns to continue testing bug fixes for problems that are causing me to continue using 0.20.4 as my primary FOP, but I'd like to continue testing 0.20.5x. I really like the speed bump (40% is suh-weet!) I get when running 0.20.5rc & 0.20.5rc2, but some of the bugs are showstoppers for me (especially 17472 & 15936). Perhaps it is just that I don't understand why we would want to limit the number of release candidates? Another potential problem, is that I'm having problems figuring out how to use our CVS system. Is there an FAQ somewhere? As for 0.20.5rc3, I'd like to see another Release Candidate ASAP (why wait for two weeks--other than the hope that more hyphenation patterns will be released). I figure if we put a new RC on the download page, people will use it and report any new bugs they find. ;-p Respectfully, Web Maestro Clay Christian Geisert wrote: > Yes, another RC makes sense but I'm a bit unsure about the > timeframe because I'd like 0.20.5rc3 to be the last RC before > releasing 0.20.5 (i.e at best no changes after rc3) but there > is still the issue with the hyphenation patterns which will > probably take some to be solved as we we shouldn't use LPPL > stuff (did I understand this right?) > > So what about rc3 in two weeks and then really stop with the > maintenance branch? -- 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]
0.20.5rc3 (was Re: PDF Encryption: Clarification)
J.Pietschmann wrote: [..] Because hyphenation license updates seem to be slow, what about doing an rc3 in 10-15 days? We'll get rid of this duplicated text problem which poeple complain about much too often and get also a more thourough test of the encryption stuff. Yes, another RC makes sense but I'm a bit unsure about the timeframe because I'd like 0.20.5rc3 to be the last RC before releasing 0.20.5 (i.e at best no changes after rc3) but there is still the issue with the hyphenation patterns which will probably take some to be solved as we we shouldn't use LPPL stuff (did I understand this right?) So what about rc3 in two weeks and then really stop with the maintenance branch? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption: Clarification
Jeremias Maerki wrote: You lost me. Error reporting: line numbers for FO's? Yes. Maint branch or trunk??? Maintenance. I though it was limited errort but it got out of hand. We may have to rework the concept for HEAD. So, do I get you right that you want (me) to follow up on that idea to use trunk's PDF lib in the maint branch??? I'd rather not. If someone else does, ok. I'd rather move forward in the trunk. It might be interesting to get the HAED PDF renderer code tested a bit more thouroughly, if this could be arranged easily. If not, well, its better to work on HEAD. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption: Clarification
On 28.03.2003 20:44:27 J.Pietschmann wrote: > Jeremias Maerki wrote: > > As I thought, not so easy. > Well, never mind. > > > A possible > > solution, though dangerous ATM, would be to dump the maintenance branch > > PDF lib and use the one from the trunk. :-) > > Keiron once noted there were severe API changes. Well, my latest changes made it necessary to revisit all the places where PDFObjects were created (PDFFactory). The problem is not the PDF lib itself, I think, but the dependant things such as the whole font story that has also change quite a bit. > If you still want > to look at it, I have a voluminous path for better error reporting > in the works but it should be ready next week and you have free reign. You lost me. Error reporting: line numbers for FO's? Maint branch or trunk??? > Because hyphenation license updates seem to be slow, what about > doing an rc3 in 10-15 days? We'll get rid of this duplicated text > problem which poeple complain about much too often and get also > a more thourough test of the encryption stuff. Don't remind me of the license stuff. There's still s much work. Worst of all: It's no fun. :-( So, do I get you right that you want (me) to follow up on that idea to use trunk's PDF lib in the maint branch??? I'd rather not. If someone else does, ok. I'd rather move forward in the trunk. Other opinions? (I might be persuaded to do it.) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption: Clarification
J.Pietschmann wrote: Because hyphenation license updates seem to be slow, what about doing an rc3 in 10-15 days? We'll get rid of this duplicated text problem which poeple complain about much too often and get also a more thourough test of the encryption stuff. Here's my non-committer's obligatory 1,000,000 vote (if even one of those 1,000,000 non-votes count or effect the release of a new, improved 0.20.5rc3, then Yah! ;-p) The "Text is duplicated" bug in 0.20.5rc2(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18468) bit me on the rears and so I've had to revert back to 0.20.4 'til there's a fix. -- 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: Clarification
Jeremias Maerki wrote: As I thought, not so easy. Well, never mind. A possible solution, though dangerous ATM, would be to dump the maintenance branch PDF lib and use the one from the trunk. :-) Keiron once noted there were severe API changes. If you still want to look at it, I have a voluminous path for better error reporting in the works but it should be ready next week and you have free reign. Because hyphenation license updates seem to be slow, what about doing an rc3 in 10-15 days? We'll get rid of this duplicated text problem which poeple complain about much too often and get also a more thourough test of the encryption stuff. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption: Clarification
As I thought, not so easy. To do that in maintenance branch I would have to backport a lot of changes I did in the PDF library. Problems: - No access to the PDFDocument from the spot where filters are applied to find out if encryption is active. - The application of encryption is pretty much scattered around in the library. It simply takes too much time for a relatively small benefit. A possible solution, though dangerous ATM, would be to dump the maintenance branch PDF lib and use the one from the trunk. :-) On 28.03.2003 07:46:02 Jeremias Maerki wrote: > Hmm, not so easy. I'll have a look. > > On 27.03.2003 23:04:50 J.Pietschmann wrote: > > Jeremias Maerki wrote: > > > Ok, I've done so. ASCII filters such as ASCII85 and ASCIIHex will be > > > disabled/ignored when encryption is active. > > > > Can you fix the maintenance branch too (if not already done)? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption: Clarification
Hmm, not so easy. I'll have a look. On 27.03.2003 23:04:50 J.Pietschmann wrote: > Jeremias Maerki wrote: > > Ok, I've done so. ASCII filters such as ASCII85 and ASCIIHex will be > > disabled/ignored when encryption is active. > > Can you fix the maintenance branch too (if not already done)? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption: Clarification
Jeremias Maerki wrote: Ok, I've done so. ASCII filters such as ASCII85 and ASCIIHex will be disabled/ignored when encryption is active. Can you fix the maintenance branch too (if not already done)? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption: Clarification
Ok, I've done so. ASCII filters such as ASCII85 and ASCIIHex will be disabled/ignored when encryption is active. On 15.03.2003 17:18:41 Patrick C. Lankswert wrote: > From my understanding of the spec, encryption MUST be the last step. > Encryption will not make the size grow, but it does negate any benefit that > ASCII85 or ASCIIHEX filters provide and THEY do make the file larger. > > In a nutshell, I would disable the ASCII85 or ASCIIHEX filters, if > encryption is enabled. > > Pat > > -Original Message- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2003 4:13 AM > To: [EMAIL PROTECTED] > Subject: PDF Encryption: Clarification > > > Do I interpret the PDF specs correctly that if encryption is applied it > doesn't make sense to apply ASCII85 or ASCIIHEX filters, because the > generated PDF will always be binary and the filters only increase the > file size? So, these two filters could be disabled in this case. Right? > > Here's the key paragraph from PDF 1.3, page 64: > > Stream data is encrypted after all stream encoding filters have been > applied (and is > > decrypted before the stream decoding filters are applied). Decryption of > strings, > > other than those in the Encryption dictionary, is done after > escape-sequence > > processing and hex decoding as appropriate to the string representation > described > > in Section 4.4, Strings and text. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
On Tue, Mar 25, 2003 at 01:56:04AM +1000, Peter B. West wrote: > > > Victor Mote wrote: > > > > > >My understanding is as follows: > >1. The "refresh" button on the http://forrestbot.cocoondev.org site will > >take the contents at cvs.apache.org/cvs/xml-fop as input, and generate the > >web site. That is what is displayed at > >http://forrestbot.cocoondev.org/site/xml-fop. > >2. The "publish" button at http://forrestbot.cocoondev.org seems to > >actually > >update the cvs.apache.org/cvs/xml-site/targets/fop directory, checking the > >output from "refresh" into that repository. This is somewhat contrary to > >the > >text that appears on http://forrestbot.cocoondev.org. > > This step seems to have some problems. I have just gone through the > cycle of building locally, checking the changes into HEAD, getting > forrestbot to refresh, checking the just-constucted site, and then > getting forrestbot to publish. I had problems on the live site that I > did not see locally or on the forrestbot driver pages at > forrestbot.cocoondev.org. Specifically, an old copy of my javascript > file was in service. The script which pulls files from CVS and publishes them is only run every X hours, so the live site probably just hasn't caught up. I've verified that the codedisplay.js files displayed by forrestbot.cocoondev.org and those in xml-site/targets/fop CVS are identical. > I have noticed that redundant files do not seem to be cleaned up in the > process either - they just hang around. Yes, detecting when a file *isn't* generated is harder than detecting when one is, and the price of making a mistake is much greater, so I didn't attempt it. --Jeff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Peter B. West wrote: > This step seems to have some problems. I have just gone through the > cycle of building locally, checking the changes into HEAD, getting > forrestbot to refresh, checking the just-constucted site, and then > getting forrestbot to publish. I had problems on the live site that I > did not see locally or on the forrestbot driver pages at > forrestbot.cocoondev.org. Specifically, an old copy of my javascript > file was in service. Well, the forrestbot stuff is a black box to me right now. It may not know to look for your javascript code. Probably you'll have to check that into the "sites" repository manually to get it updated, but Jeff may have a better idea, or perhaps can provide a fix. > I have noticed that redundant files do not seem to be cleaned up in the > process either - they just hang around. I think old stuff probably needs to be retired in the "sites" repository manually, using CVS. I think this is what Jeff was referring to in an earlier posting about not being able to find a safe way to delete content. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Victor Mote wrote: My understanding is as follows: 1. The "refresh" button on the http://forrestbot.cocoondev.org site will take the contents at cvs.apache.org/cvs/xml-fop as input, and generate the web site. That is what is displayed at http://forrestbot.cocoondev.org/site/xml-fop. 2. The "publish" button at http://forrestbot.cocoondev.org seems to actually update the cvs.apache.org/cvs/xml-site/targets/fop directory, checking the output from "refresh" into that repository. This is somewhat contrary to the text that appears on http://forrestbot.cocoondev.org. This step seems to have some problems. I have just gone through the cycle of building locally, checking the changes into HEAD, getting forrestbot to refresh, checking the just-constucted site, and then getting forrestbot to publish. I had problems on the live site that I did not see locally or on the forrestbot driver pages at forrestbot.cocoondev.org. Specifically, an old copy of my javascript file was in service. I have noticed that redundant files do not seem to be cleaned up in the process either - they just hang around. 3. The 6-hour hourly script, as you say, will update the "live" web site. This seems to be what is happening. The only thing that I don't understand is that the timestamp on each page seems to correspond to the 6-hour update, not to the actual time that the web site is generated. This all works pretty well, except that, because the pdfs are binaries in the repository, there is a linear increase in size for them instead of an incremental increase. Someone will probably need to go through & obsolete old versions of them to keep the repository from getting ever bigger. If the above is incorrect, I hope that someone will post a correction. For minor doc changes, it relieves one of the necessity of maintaining a local forrest installation. For major jobs, we'll still want to have a local copy for testing before committing changes and generating the site. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
On Tue, Mar 18, 2003 at 10:04:58PM -0700, Victor Mote wrote:
> Peter B. West wrote:
>
> > That should be, "...still has to be committed." The 6-hourly script
> > will presumably update from the website CVS.
> >
> > Peter B. West wrote:
> > > Victor,
> > >
> > > I'll make and commit the changes that Jeff recommended. We can
> > > then use the bot output or out own forrest run to generate the
> > > site. It still has to be committed and the leve site updated by
> > > hand, as I understand things.
>
> My understanding is as follows:
> 1. The "refresh" button on the http://forrestbot.cocoondev.org site will
> take the contents at cvs.apache.org/cvs/xml-fop as input, and generate the
> web site. That is what is displayed at
> http://forrestbot.cocoondev.org/site/xml-fop.
> 2. The "publish" button at http://forrestbot.cocoondev.org seems to actually
> update the cvs.apache.org/cvs/xml-site/targets/fop directory, checking the
> output from "refresh" into that repository. This is somewhat contrary to the
> text that appears on http://forrestbot.cocoondev.org.
> 3. The 6-hour hourly script, as you say, will update the "live" web site.
Correct. I'll update the text.
> This seems to be what is happening. The only thing that I don't understand
> is that the timestamp on each page seems to correspond to the 6-hour update,
> not to the actual time that the web site is generated.
The timestamp is that of the file on the server, generated with
Javascript:
document.write(" - "+"Last Published: " + document.lastModified)
> This all works pretty well, except that, because the pdfs are binaries in
> the repository, there is a linear increase in size for them instead of an
> incremental increase. Someone will probably need to go through & obsolete
> old versions of them to keep the repository from getting ever bigger.
CVS isn't too bad yet (382M), considering the size of a checked-out
xml-site (158M). I suppose if icarus runs out of space we can re-import
it all to get rid of the history.
--Jeff
...
>
> Victor Mote
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Peter B. West wrote: > That should be, "...still has to be committed." The 6-hourly script > will presumably update from the website CVS. > > Peter B. West wrote: > > Victor, > > > > I'll make and commit the changes that Jeff recommended. We can > then use > > the bot output or out own forrest run to generate the site. It still > > has to be committed and the leve site updated by hand, as I understand > > things. My understanding is as follows: 1. The "refresh" button on the http://forrestbot.cocoondev.org site will take the contents at cvs.apache.org/cvs/xml-fop as input, and generate the web site. That is what is displayed at http://forrestbot.cocoondev.org/site/xml-fop. 2. The "publish" button at http://forrestbot.cocoondev.org seems to actually update the cvs.apache.org/cvs/xml-site/targets/fop directory, checking the output from "refresh" into that repository. This is somewhat contrary to the text that appears on http://forrestbot.cocoondev.org. 3. The 6-hour hourly script, as you say, will update the "live" web site. This seems to be what is happening. The only thing that I don't understand is that the timestamp on each page seems to correspond to the 6-hour update, not to the actual time that the web site is generated. This all works pretty well, except that, because the pdfs are binaries in the repository, there is a linear increase in size for them instead of an incremental increase. Someone will probably need to go through & obsolete old versions of them to keep the repository from getting ever bigger. If the above is incorrect, I hope that someone will post a correction. For minor doc changes, it relieves one of the necessity of maintaining a local forrest installation. For major jobs, we'll still want to have a local copy for testing before committing changes and generating the site. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
That should be, "...still has to be committed." The 6-hourly script will presumably update from the website CVS. Peter B. West wrote: Victor, I'll make and commit the changes that Jeff recommended. We can then use the bot output or out own forrest run to generate the site. It still has to be committed and the leve site updated by hand, as I understand things. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Victor, I'll make and commit the changes that Jeff recommended. We can then use the bot output or out own forrest run to generate the site. It still has to be committed and the leve site updated by hand, as I understand things. Peter Victor Mote wrote: Peter B. West wrote: ... I just took a look, and the .js files is not being picked up. It *might* be OK provided the live site update doesn't prune redundant files. Peter: I have seen the remaining items in this thread, and concluded that this is all OK. Please let me know if that is not true. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Peter B. West wrote: > Victor, > > There's a slight problem here. My files can only be built successfully > with a mod to forrest.build.xml that copies the contents of > resources/scripts into context. If forrestbot is building off CVS with > a slightly elderly version (and I understand the current CVS is going to > be a little broken for a while) the file codedisplay.js will not be > picked up. > > I just took a look, and the .js files is not being picked up. > > It *might* be OK provided the live site update doesn't prune redundant > files. Peter: I have seen the remaining items in this thread, and concluded that this is all OK. Please let me know if that is not true. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] small doc fixes (Re: Encryption)
Jeff Turner wrote: > > Then the only broken files are: > > > > -> [broken page] pdf-security.html <- > > -> [broken page] dev/output.html <- > > The attached patch fixes these two. Thanks very much. I have just committed these changes. I will probably be regenerating the site later in the day. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] small doc fixes (Re: Encryption)
On Tue, Mar 18, 2003 at 08:03:42PM +1100, Jeff Turner wrote: ... > Instead of modifying Forrest, if you copy the *.js files from resources/* > to content/*, so you have: > > [xml-fop ~/src/documentation/content]$ find . -name "codedisplay.js" > ./design/alt.design/properties/codedisplay.js > ./design/alt.design/codedisplay.js > > Then the scripts are copied across. > > Then the only broken files are: > > -> [broken page] pdf-security.html <- > -> [broken page] dev/output.html <- The attached patch fixes these two. --Jeff ? src/documentation/content/design/alt.design/codedisplay.js ? src/documentation/content/design/alt.design/properties/codedisplay.js Index: src/documentation/content/xdocs/faq.xml === RCS file: /home/cvspublic/xml-fop/src/documentation/content/xdocs/faq.xml,v retrieving revision 1.12 diff -u -r1.12 faq.xml --- src/documentation/content/xdocs/faq.xml 15 Mar 2003 19:55:49 - 1.12 +++ src/documentation/content/xdocs/faq.xml 18 Mar 2003 11:22:48 - @@ -957,7 +957,7 @@ for adding security features, document properties, watermarks, and many other features to PDF files. FOP and iText can be integrated into one Java application, see sample code for encryption. + href="#pdf-security">encryption. The bad news is that iText swallows PDF bookmarks. Index: src/documentation/content/xdocs/dev/faq.xml === RCS file: /home/cvspublic/xml-fop/src/documentation/content/xdocs/dev/faq.xml,v retrieving revision 1.5 diff -u -r1.5 faq.xml --- src/documentation/content/xdocs/dev/faq.xml 12 Dec 2002 10:59:33 - 1.5 +++ src/documentation/content/xdocs/dev/faq.xml 18 Mar 2003 11:22:53 - @@ -812,7 +812,7 @@ Answers are that fonts must be available for the output format, and the selected font must contain glyphs for the desired character. -PDF has a set of defined fonts, other fonts can be embedded following the + PDF has a set of defined fonts, other fonts can be embedded following the instructions. To find out if the characters you need are in the core fonts then (todo - find a glyph font table for the fonts). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
On Tue, Mar 18, 2003 at 05:30:47PM +1000, Peter B. West wrote: > Victor, > > There's a slight problem here. My files can only be built successfully > with a mod to forrest.build.xml that copies the contents of > resources/scripts into context. If forrestbot is building off CVS with > a slightly elderly version (and I understand the current CVS is going to > be a little broken for a while) the file codedisplay.js will not be > picked up. > > I just took a look, and the .js files is not being picked up. Instead of modifying Forrest, if you copy the *.js files from resources/* to content/*, so you have: [xml-fop ~/src/documentation/content]$ find . -name "codedisplay.js" ./design/alt.design/properties/codedisplay.js ./design/alt.design/codedisplay.js Then the scripts are copied across. Then the only broken files are: -> [broken page] pdf-security.html <- -> [broken page] dev/output.html <- > It *might* be OK provided the live site update doesn't prune redundant > files. The Forrestbot publish script doesn't, mainly because I couldn't figure out a safe way to do so. --Jeff > Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Jeremias, Forrest CVS. I modified forrest.build.xml in my xml-forrest tree to get it to locate the .js files. I haven't tried a cvs up on forrest because of warnings that things might be a bit unstable ATM. Peter Jeremias Maerki wrote: Peter, which one is broken, forrest CVS or fop CVS? -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Peter, which one is broken, forrest CVS or fop CVS? On 18.03.2003 08:30:47 Peter B. West wrote: > There's a slight problem here. My files can only be built successfully > with a mod to forrest.build.xml that copies the contents of > resources/scripts into context. If forrestbot is building off CVS with > a slightly elderly version (and I understand the current CVS is going to > be a little broken for a while) the file codedisplay.js will not be > picked up. > > I just took a look, and the .js files is not being picked up. > > It *might* be OK provided the live site update doesn't prune redundant > files. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Victor, There's a slight problem here. My files can only be built successfully with a mod to forrest.build.xml that copies the contents of resources/scripts into context. If forrestbot is building off CVS with a slightly elderly version (and I understand the current CVS is going to be a little broken for a while) the file codedisplay.js will not be picked up. I just took a look, and the .js files is not being picked up. It *might* be OK provided the live site update doesn't prune redundant files. Peter Victor Mote wrote: Keiron Liddle wrote: Peter, Keiron: how is the web site updated? I thought there was a cron job every few hours? Currently it only updates the site here: http://forrestbot.cocoondev.com (seems to be down at the moment) From this site you can update the main site by entering the correct name/password, I'll send offlist. OK, I am a little slow, but I finally figured out that this URL should be http://forrestbot.cocoondev.org. Once you get there, there are instructions about obtaining a password. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Keiron Liddle wrote: > > Peter, Keiron: how is the web site updated? I thought there was a > > cron job every few hours? > > Currently it only updates the site here: > http://forrestbot.cocoondev.com (seems to > be down at the moment) > From this site you can update the main site by entering the correct > name/password, I'll send offlist. OK, I am a little slow, but I finally figured out that this URL should be http://forrestbot.cocoondev.org. Once you get there, there are instructions about obtaining a password. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption: Clarification
Jeremias, >From my understanding of the spec, encryption MUST be the last step. Encryption will not make the size grow, but it does negate any benefit that ASCII85 or ASCIIHEX filters provide and THEY do make the file larger. In a nutshell, I would disable the ASCII85 or ASCIIHEX filters, if encryption is enabled. Pat -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 4:13 AM To: [EMAIL PROTECTED] Subject: PDF Encryption: Clarification Do I interpret the PDF specs correctly that if encryption is applied it doesn't make sense to apply ASCII85 or ASCIIHEX filters, because the generated PDF will always be binary and the filters only increase the file size? So, these two filters could be disabled in this case. Right? Here's the key paragraph from PDF 1.3, page 64: > Stream data is encrypted after all stream encoding filters have been applied (and is > decrypted before the stream decoding filters are applied). Decryption of strings, > other than those in the Encryption dictionary, is done after escape-sequence > processing and hex decoding as appropriate to the string representation described > in Section 4.4, Strings and text. 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
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]
PDF Encryption: Clarification
Do I interpret the PDF specs correctly that if encryption is applied it doesn't make sense to apply ASCII85 or ASCIIHEX filters, because the generated PDF will always be binary and the filters only increase the file size? So, these two filters could be disabled in this case. Right? Here's the key paragraph from PDF 1.3, page 64: > Stream data is encrypted after all stream encoding filters have been applied (and is > decrypted before the stream decoding filters are applied). Decryption of strings, > other than those in the Encryption dictionary, is done after escape-sequence > processing and hex decoding as appropriate to the string representation described > in Section 4.4, Strings and text. 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: Encryption
Proofed it. Corrected a few typos and added a link to the PDF Reference. In
a couple more days, I'll read over it again.
Pat
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 3:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Encryption
Patrick C. Lankswert wrote:
> If there is anything you need reworked, just let me know.
No problem apart from the surprise.
I wrote up something in pdfencryption.xml, checked in in HEAD (not
the maintenance branch). If you (or someone else) would proofread
it, in order to spare others the trouble...
Again, did anyone try the Mozilla JCE impl?
Any other OSS implementation (besides BouncyCastle) which
includes RC4?
What about commercial stuff?
Peter, Keiron: how is the web site updated? I thought there was a
cron job every few hours?
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd";>
PDF encryption.
Overview
FOP supports encryption of PDF output, thanks to Patrick
C. Lankswert. This feature is commonly used to prevent unauthorized
printing, editing and copying text from the document or to forbid
annotations. It is also possible to ask the user for a password in order
to view the contents. Note that there already exist third party
applications which can decrypt an encrypted PDF without effort and allow
the aforementioned operations, therefore the degree of protection is
limited.
For further information about features and restrictions regarrding PDFF
encryption, look at the documentation coming with Adobe Acrobat or the
technial documentation on the Adobe web site.
Usage
Encryption is enabled by supplying an owner password with the
-o option. The owner password can be used to disregard
any restriction imposed on the PDF document. If no owner password has
been supplied but FOP was asked to apply some restrictions, a random
password is used.
A user password, supplied with the -u option, will
cause the PDF display software to ask the reader for this password in
order to view the contents of the document. If no user password was
supplied, viewing the content is not restricted.
Further restrictions can be imposed by using the
-noprint, -nocopy,
-noedit and -noannotations options,
which disable printing, copy text, editing in Adobe Acrobat and making
annotations, respectively.
Environment
In order to use PDF encryption, FOP has to be compiled with cryptography
support. Currently, only http://java.sun.com/j2se/1.4/docs/guide/security/jce/JCERefGuide.html";>JCE
is supported. JCE is part of JDK 1.4. For earlier JDKs, it can be
installed separately, however, the build process currently recognizes
JCE from JDK 1.4.
Cryptography support must also be present at run time. In particular, a
provider for the RC4 cipher is needed. Unfortunately, the sample JCE
provider in Sun's JDK 1.4 does not provide RC4. If you
get a message saying
"Cannot find any provider supporting RC4"
you don't have the needed support.
There are several commercial and a few Open Source packages which
provide RC4. A pure Java implementation is produced by http://www.bouncycastle.org/";>The Legion of the Bouncy
Castle. http://www.mozilla.org/projects/security/pki/jss/";>Mozilla
JSS is an interface to a native implementation.
Installing a crypto provider
The pure Java implementation from http://www.bouncycastle.org/";>Bouncy Castle is easy to
install.
Download the binary distribution for your JDK version. If you have JDK
1.3 or earlier you must alos download a JCE from the same page.
Unpack the distribution. Add the jar file to your classpath. A
convenient way to use the jar on Linux is to simply drop it into the
FOP lib directory, it will be automatically picked up by
fop.sh. If you have JDK 1.3 or earlier don't forget to
install the JCE as well.
Open the java.security file and add
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider,
preferably at the end of the block defining the other crypto
providers. For JDK 1.4 this is detailed on http://java.sun.com/
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]
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]
RE: Encryption
Peter B. West wrote: > Keiron Liddle wrote: > >>Peter, Keiron: how is the web site updated? I thought there was a > >>cron job every few hours? > > > > > > Currently it only updates the site here: > http://forrestbot.cocoondev.com (seems to > > be down at the moment) > >>From this site you can update the main site by entering the correct > > name/password, I'll send offlist. > > Yes please. I didn't understand this part. Currently I am trying to > sort out some documentation problems. I would like to get this as well please. Thank you. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Keiron Liddle wrote: Peter, Keiron: how is the web site updated? I thought there was a cron job every few hours? Currently it only updates the site here: http://forrestbot.cocoondev.com (seems to be down at the moment) From this site you can update the main site by entering the correct name/password, I'll send offlist. Yes please. I didn't understand this part. Currently I am trying to sort out some documentation problems. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
> Peter, Keiron: how is the web site updated? I thought there was a > cron job every few hours? Currently it only updates the site here: http://forrestbot.cocoondev.com (seems to be down at the moment) >From this site you can update the main site by entering the correct name/password, I'll send offlist. > J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Patrick C. Lankswert wrote: If there is anything you need reworked, just let me know. No problem apart from the surprise. I wrote up something in pdfencryption.xml, checked in in HEAD (not the maintenance branch). If you (or someone else) would proofread it, in order to spare others the trouble... Again, did anyone try the Mozilla JCE impl? Any other OSS implementation (besides BouncyCastle) which includes RC4? What about commercial stuff? Peter, Keiron: how is the web site updated? I thought there was a cron job every few hours? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
I agree with you concerning sticking with the standard JCE interface, but in the end I want what works. I feel for you since you have to live with my code ;-) (until someone does it better), so my tact is facilitate the transition with the minimal cost to you. If there is anything you need reworked, just let me know. Once we all agree it is production quality, I'm gonna turn around and use it... call it enlightened self-interest. Cheers and thanks again, Pat -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 2:21 PM To: [EMAIL PROTECTED] Subject: Re: Encryption Patrick C. Lankswert wrote: > Add jce-jdk13-118.jar (for 1.3.x) to %JAVA_HOME%\jre\lib\ext and add > security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider > to %JAVA_HOME%\jre\lib\security\java.security in the appropriate section. > This should work. This is how it is done to support any implementation. Thank you, I already discovered this myself last night. It was just that shutting down the work environment in order to re-login as Administrator for changing java.security at 2:10am isn't worth it, so I decided to go to bed. Now everything runs well and is already committed to the maintenance branch, I'll update the docs and HEAD later. > IF you would like it HARD CODED to bouncy castle's implementation which does > not require the java.security changes, It's probably a bad idea to tie FOP to a specific provider. In particular as Mozilla also has an Open Source implementation, which is perhaps even faster due to native code (anybody ready to try it?) 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: Encryption
Patrick C. Lankswert wrote: Add jce-jdk13-118.jar (for 1.3.x) to %JAVA_HOME%\jre\lib\ext and add security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider to %JAVA_HOME%\jre\lib\security\java.security in the appropriate section. This should work. This is how it is done to support any implementation. Thank you, I already discovered this myself last night. It was just that shutting down the work environment in order to re-login as Administrator for changing java.security at 2:10am isn't worth it, so I decided to go to bed. Now everything runs well and is already committed to the maintenance branch, I'll update the docs and HEAD later. IF you would like it HARD CODED to bouncy castle's implementation which does not require the java.security changes, It's probably a bad idea to tie FOP to a specific provider. In particular as Mozilla also has an Open Source implementation, which is perhaps even faster due to native code (anybody ready to try it?) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Add jce-jdk13-118.jar (for 1.3.x) to %JAVA_HOME%\jre\lib\ext and add security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider to %JAVA_HOME%\jre\lib\security\java.security in the appropriate section. This should work. This is how it is done to support any implementation. IF you would like it HARD CODED to bouncy castle's implementation which does not require the java.security changes, I can do that also. I'm sorry that I did not get this message earlier. Pat -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 8:23 PM To: [EMAIL PROTECTED] Subject: Re: Encryption Patrick C. Lankswert wrote: > Thanks... if there are any issues or work that is needed, I'm MORE than > happy to help. I got the JDK 1.3 compatibility now. However, while testing the encryption I'm getting "Cannot find any provider supporting RC4" The JCE doc for JDK1.4 at http://java.sun.com/j2se/1.4/docs/guide/security/jce/JCERefGuide.html does not mention a RC4 implementation (odd). Well, Mozilla has one, but it requires installing a DLL. Finally, BouncyCastle has another one, but it seem I can't get it to work. Do I really have to edit the JRE's java.security file? I made it writable for Administrator only, for enhanced security, and there is no su on Win2k. I'm sort of pissed now. I'll look tomorrow after this (ok it is already tomorrow...) 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: Encryption
Would you prefer a direct use of the bouncycastle crypto or modification to the build that tests the JDK? Pat -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Sunday, March 02, 2003 5:59 PM To: [EMAIL PROTECTED] Subject: Re: Encryption J.Pietschmann wrote: > Patrick C. Lankswert wrote: > >> Has anybody looked at this? > > Yes. I'm currently in the process of integrating the stuff. I'll have to do some more test, in particular for JDK1.3 compatibility (no javax.crypto there). Commit deferred to next Friday. 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: Encryption
Patrick C. Lankswert wrote: Thanks... if there are any issues or work that is needed, I'm MORE than happy to help. I got the JDK 1.3 compatibility now. However, while testing the encryption I'm getting "Cannot find any provider supporting RC4" The JCE doc for JDK1.4 at http://java.sun.com/j2se/1.4/docs/guide/security/jce/JCERefGuide.html does not mention a RC4 implementation (odd). Well, Mozilla has one, but it requires installing a DLL. Finally, BouncyCastle has another one, but it seem I can't get it to work. Do I really have to edit the JRE's java.security file? I made it writable for Administrator only, for enhanced security, and there is no su on Win2k. I'm sort of pissed now. I'll look tomorrow after this (ok it is already tomorrow...) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
J.Pietschmann wrote: Patrick C. Lankswert wrote: Has anybody looked at this? Yes. I'm currently in the process of integrating the stuff. I'll have to do some more test, in particular for JDK1.3 compatibility (no javax.crypto there). Commit deferred to next Friday. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Thanks... if there are any issues or work that is needed, I'm MORE than happy to help. Pat -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Sunday, March 02, 2003 12:35 PM To: [EMAIL PROTECTED] Subject: Re: Encryption Patrick C. Lankswert wrote: > Has anybody looked at this? Yes. I'm currently in the process of integrating the stuff. 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: Encryption
Patrick C. Lankswert wrote: Has anybody looked at this? Yes. I'm currently in the process of integrating the stuff. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Hey, Has anybody looked at this? It's been two weeks since I submitted it and I have not heard anything. Did I miss something? I'd like to get this included before the code base changes and I have to reimplement by hand. Pat Lankswert -Original Message- From: Patrick C. Lankswert [mailto:[EMAIL PROTECTED] Sent: Thursday, February 13, 2003 10:36 PM To: [EMAIL PROTECTED] Subject: Encryption To all that may concern, Here it is... PDF encryption. Unfortunately, I seem to be lame when it comes to cvs. When I generate the unified using WinCVS's "cvs diff -uN", it does not include the file PDFEncryption.java. I have included it as a second attachment. It belongs in src/org/apache/fop/pdf. Send me all of your nice and nasty comments and I'll make any adjustments necessary. Enjoy, Pat Lankswert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Encryption
To all that may concern,
Here it is... PDF encryption. Unfortunately, I seem to be lame when it comes
to cvs. When I generate the unified using WinCVS's "cvs diff -uN", it does
not include the file PDFEncryption.java. I have included it as a second
attachment. It belongs in src/org/apache/fop/pdf.
Send me all of your nice and nasty comments and I'll make any adjustments
necessary.
Enjoy,
Pat Lankswert
? xml-fop/build/fop.jar
? xml-fop/build/src
? xml-fop/build/classes/hyph
? xml-fop/build/classes/org
? xml-fop/build/classes/conf/config.dtd
? xml-fop/build/classes/conf/config.xml
? xml-fop/build/classes/conf/userconfig.xml
? xml-fop/src/org/apache/fop/pdf/.nbattrs
? xml-fop/src/org/apache/fop/pdf/PDFEncryption.java
? xml-fop/src/org/apache/fop/render/pdf/.nbattrs
Index: xml-fop/fop.bat
===
RCS file: /home/cvspublic/xml-fop/fop.bat,v
retrieving revision 1.4.2.8
diff -u -r1.4.2.8 fop.bat
--- xml-fop/fop.bat 10 Dec 2002 22:28:02 - 1.4.2.8
+++ xml-fop/fop.bat 14 Feb 2003 03:28:18 -
@@ -10,4 +10,4 @@
set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jimi-1.0.jar
set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jai_core.jar
set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jai_codec.jar
-java -cp %LOCALCLASSPATH% org.apache.fop.apps.Fop %1 %2 %3 %4 %5 %6 %7 %8
\ No newline at end of file
+java -cp %LOCALCLASSPATH% org.apache.fop.apps.Fop %*
\ No newline at end of file
Index: xml-fop/src/org/apache/fop/apps/CommandLineOptions.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/apps/CommandLineOptions.java,v
retrieving revision 1.14.2.8
diff -u -r1.14.2.8 CommandLineOptions.java
--- xml-fop/src/org/apache/fop/apps/CommandLineOptions.java 19 Nov 2002 00:47:01
- 1.14.2.8
+++ xml-fop/src/org/apache/fop/apps/CommandLineOptions.java 14 Feb 2003 03:28:34
+-
@@ -177,6 +177,52 @@
outfile = new File(args[i + 1]);
i++;
}
+} else if (args[i].equals("-o")) {
+if (inputmode == PDF_OUTPUT) {
+if ((i + 1 == args.length) || (args[i + 1].charAt(0) == '-')) {
+rendererOptions.put("ownerPassword", "");
+} else {
+rendererOptions.put("ownerPassword", args[i + 1]);
+i++;
+}
+} else {
+throw new FOPException("Owner password can only be set for PDF
+output");
+}
+} else if (args[i].equals("-u")) {
+if (inputmode == PDF_OUTPUT) {
+if ((i + 1 == args.length) || (args[i + 1].charAt(0) == '-')) {
+rendererOptions.put("userPassword", "");
+} else {
+rendererOptions.put("userPassword", args[i + 1]);
+i++;
+}
+} else {
+throw new FOPException("User password can only be set for PDF
+output");
+}
+} else if (args[i].equals("-noprint")) {
+if (inputmode == PDF_OUTPUT) {
+rendererOptions.put("allowPrint", "FALSE");
+} else {
+throw new FOPException("NoPrint can only be set for PDF output");
+}
+} else if (args[i].equals("-nocopy")) {
+if (inputmode == PDF_OUTPUT) {
+rendererOptions.put("allowCopyContent", "FALSE");
+} else {
+throw new FOPException("NoCopyContent can only be set for PDF
+output");
+}
+} else if (args[i].equals("-noedit")) {
+if (inputmode == PDF_OUTPUT) {
+rendererOptions.put("allowEditContent", "FALSE");
+} else {
+throw new FOPException("NoEditContent can only be set for PDF
+output");
+}
+} else if (args[i].equals("-noannotations")) {
+if (inputmode == PDF_OUTPUT) {
+rendererOptions.put("allowEditAnnotations", "FALSE");
+} else {
+throw new FOPException("NoAnnotations can only be set for PDF
+output");
+}
} else if (args[i].equals("-mif")) {
setOutputMode(MIF_OUTPUT);
if ((i + 1 == args.length)
@@ -507,6 +553,12 @@
+ " [OUTPUT] \n"
+ " outfile
RE: Encryption
Chris, Thanks... Pat -Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 5:24 AM To: [EMAIL PROTECTED] Subject: RE: Encryption >From: "Patrick C. Lankswert" <[EMAIL PROTECTED]> >However, it does not seem to support the CVS diff command. When I select >diff, it gives me a visual comparison. I assume that CVS diff is like the >UN*X command line diff for use with patch... can anybody help. >Unfortunately, I am on a Windows platform as that is our development >platform at work. > I believe you can use WinCVS to get the unified diff. WinCVS can be downloaded at http://www.wincvs.org/download.html _ Use MSN Messenger to send music and pics to your friends http://messenger.msn.co.uk - 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: Encryption
From: "Patrick C. Lankswert" <[EMAIL PROTECTED]> However, it does not seem to support the CVS diff command. When I select diff, it gives me a visual comparison. I assume that CVS diff is like the UN*X command line diff for use with patch... can anybody help. Unfortunately, I am on a Windows platform as that is our development platform at work. I believe you can use WinCVS to get the unified diff. WinCVS can be downloaded at http://www.wincvs.org/download.html _ Use MSN Messenger to send music and pics to your friends http://messenger.msn.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Jeremias (et al.), I have implemented the changes as prescribed and tested it with several fo files containing text and graphics. Everything looks good so far. I have two open issues: 1) I have implemented the encryption through the command line interface and renderOptions. Should it have been implemented to use the config.xml instead? Both? 2) I am using Forte 4.0 CE and the built-in CVS engine. checkout was great. However, it does not seem to support the CVS diff command. When I select diff, it gives me a visual comparison. I assume that CVS diff is like the UN*X command line diff for use with patch... can anybody help. Unfortunately, I am on a Windows platform as that is our development platform at work. Otherwise, I ready to submit this. Pat -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 3:07 AM To: [EMAIL PROTECTED] Subject: Re: Encryption Hi Patrick On 10.02.2003 06:17:26 Patrick C. Lankswert wrote: > Ok... with two separate weekends of the stomach flu in my house, it took a > little longer than I had hoped. However, I have a working copy of the V1 R2 > encryption with support for user and owner passwords, print, copy, content > edit and annotation edit control written against v0.20.4. Some more QC and > commenting and it will be ready for submission. I have command line control > of options which are passed to the renderer via renderOptions. All > encryption is support via bouncecastle's provider. Now a couple questions > before I submit it. > > 1) Which version do the committers want this verified? 0.20.4 or 0.20.4rc? Neither. We're already having 0.20.5rc and approaching 0.20.5. :-) You should provide a unified CVS diff against the maintenance branch (CVS tag "fop-0_20_2-maintain"). > 2) Where can I find some complicated fo files for transforming and testing? There's only the examples in the FOP distribution. But I think you'll find other examples when searching the mailing list archives. > 3) Is anybody interested in helping to test this? I'm concentrating on the redesign. I'd rather help there. > 4) I would like to implement the PDF 1.4 version V2 for the fop redesign... > is anybody interested? Yup. Everything that brings the redesign forward is welcome. 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: Encryption
Hi Patrick On 10.02.2003 06:17:26 Patrick C. Lankswert wrote: > Ok... with two separate weekends of the stomach flu in my house, it took a > little longer than I had hoped. However, I have a working copy of the V1 R2 > encryption with support for user and owner passwords, print, copy, content > edit and annotation edit control written against v0.20.4. Some more QC and > commenting and it will be ready for submission. I have command line control > of options which are passed to the renderer via renderOptions. All > encryption is support via bouncecastle's provider. Now a couple questions > before I submit it. > > 1) Which version do the committers want this verified? 0.20.4 or 0.20.4rc? Neither. We're already having 0.20.5rc and approaching 0.20.5. :-) You should provide a unified CVS diff against the maintenance branch (CVS tag "fop-0_20_2-maintain"). > 2) Where can I find some complicated fo files for transforming and testing? There's only the examples in the FOP distribution. But I think you'll find other examples when searching the mailing list archives. > 3) Is anybody interested in helping to test this? I'm concentrating on the redesign. I'd rather help there. > 4) I would like to implement the PDF 1.4 version V2 for the fop redesign... > is anybody interested? Yup. Everything that brings the redesign forward is welcome. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Jeremias, Ok... with two separate weekends of the stomach flu in my house, it took a little longer than I had hoped. However, I have a working copy of the V1 R2 encryption with support for user and owner passwords, print, copy, content edit and annotation edit control written against v0.20.4. Some more QC and commenting and it will be ready for submission. I have command line control of options which are passed to the renderer via renderOptions. All encryption is support via bouncecastle's provider. Now a couple questions before I submit it. 1) Which version do the committers want this verified? 0.20.4 or 0.20.4rc? 2) Where can I find some complicated fo files for transforming and testing? 3) Is anybody interested in helping to test this? 4) I would like to implement the PDF 1.4 version V2 for the fop redesign... is anybody interested? Pat Lankswert -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 1:50 AM To: [EMAIL PROTECTED] Subject: Re: Encryption Hi Patrick Because still noone has started working on it? :-) It's one of the most requested features. On the other side, iText seems to work for those who want to add encryption. Would you like to help? We can use all the help we can get. On 09.01.2003 07:34:09 Patrick C. Lankswert wrote: > I tried to determine the reason from the archives with clarity... but why > isn't PDF encryption in the core? 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: Encryption
Jeremias, Ok... it now works with bouncycastle's implementation. I need to add a couple more days, we are moving our offices. It was majorly bungled and it is eating up a lot of time. Pat -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 2:07 AM To: [EMAIL PROTECTED] Subject: Re: Encryption Hi Patrick That's great news! I'll be glad to help testing and integrating. But one question: Why would you want to implement RC4 yourself? Wouldn't it be better if we used (for example) bouncycastle.org's implementation for that? They have an MIT licence which is compatible with the APL AFAIK. You wouldn't have to do any debugging and testing on the cryptography stuff that way. On 10.01.2003 00:25:16 Patrick C. Lankswert wrote: > Thanks for the reply. Outside of clean up, I have working code. It is > limited since only PDF 1.3 is supported by FOP and I am currently using a > non-commercial RC4 implementation. If I get the time, I could have it > cleaned up in a week and a half. It might be a little longer if I go ahead > and implement RC4 myself. I might need some help testing, but I already have > it generating encrypted PDFs with and without passwords, permissions etc. 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: Encryption
> Jeremias, > > Thanks for the reply. Outside of clean up, I have working code. It is > limited since only PDF 1.3 is supported by FOP and I am currently using a The redesign code generates PDF 1.4 (which currently is used in a completely backwards/forwards compatible way). How does the compatibilty of encryption work. Can it have the 1.4 features and still work in 1.3? > non-commercial RC4 implementation. If I get the time, I could have it > cleaned up in a week and a half. It might be a little longer if I go ahead > and implement RC4 myself. I might need some help testing, but I already have > it generating encrypted PDFs with and without passwords, permissions etc. > > Pat Lankswert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Hi Patrick That's great news! I'll be glad to help testing and integrating. But one question: Why would you want to implement RC4 yourself? Wouldn't it be better if we used (for example) bouncycastle.org's implementation for that? They have an MIT licence which is compatible with the APL AFAIK. You wouldn't have to do any debugging and testing on the cryptography stuff that way. On 10.01.2003 00:25:16 Patrick C. Lankswert wrote: > Thanks for the reply. Outside of clean up, I have working code. It is > limited since only PDF 1.3 is supported by FOP and I am currently using a > non-commercial RC4 implementation. If I get the time, I could have it > cleaned up in a week and a half. It might be a little longer if I go ahead > and implement RC4 myself. I might need some help testing, but I already have > it generating encrypted PDFs with and without passwords, permissions etc. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Jeremias, Thanks for the reply. Outside of clean up, I have working code. It is limited since only PDF 1.3 is supported by FOP and I am currently using a non-commercial RC4 implementation. If I get the time, I could have it cleaned up in a week and a half. It might be a little longer if I go ahead and implement RC4 myself. I might need some help testing, but I already have it generating encrypted PDFs with and without passwords, permissions etc. Pat Lankswert -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 1:50 AM To: [EMAIL PROTECTED] Subject: Re: Encryption Hi Patrick Because still noone has started working on it? :-) It's one of the most requested features. On the other side, iText seems to work for those who want to add encryption. Would you like to help? We can use all the help we can get. On 09.01.2003 07:34:09 Patrick C. Lankswert wrote: > I tried to determine the reason from the archives with clarity... but why > isn't PDF encryption in the core? 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: Encryption
Hi Patrick Because still noone has started working on it? :-) It's one of the most requested features. On the other side, iText seems to work for those who want to add encryption. Would you like to help? We can use all the help we can get. On 09.01.2003 07:34:09 Patrick C. Lankswert wrote: > I tried to determine the reason from the archives with clarity... but why > isn't PDF encryption in the core? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Encryption
To all, I tried to determine the reason from the archives with clarity... but why isn't PDF encryption in the core? Pat Lankswert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF encryption
Actually, 128 bit is a ver. 5.0 requirement. I'm using this exact setup in my app (iText w/ FOP for encryption), and we are requiring all users to have AcroReader 5.0 for 128 bit encryption. Also, if you encrypt at 128 bit, and then check the encryptions properties of the doc in Reader, you'll see strength 128 and next to it, 5.0 in parenthesis. -- David B. Bitton [EMAIL PROTECTED] www.codenoevil.com Code Made Fresh DailyT - Original Message - From: "J.Pietschmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, April 28, 2002 5:39 PM Subject: Re: PDF encryption > Geez, self-followup: > > writer.setEncryption(PdfWriter.STRENGTH40BITS, > "pdf", null, PdfWriter.AllowCopy); > > If I set encryption to STRENGTH128BITS, as the original > had, Acrobat Reader 4.0 complains about "Error while > decrypting". Probably an export restriction :-(, so be > careful. > > 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]
