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: 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]
