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
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
+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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
