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
+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 re
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
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 bu
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
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 se
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
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 p
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 scat
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)?
Jer
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,
IL 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
>
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
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
14 matches
Mail list logo
