You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2003/03/14 10:12:35 UTC

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: PDF Encryption: Clarification

Posted by "J.Pietschmann" <j3...@yahoo.de>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: PDF Encryption: Clarification

Posted by Jeremias Maerki <de...@greenmail.ch>.
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.

<censored what="rude four letter word"/> Don't remind me of the license
stuff. There's still soooo 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Christian Geisert wrote:
> Actually Jörg proposed a RC in 10-14 days ;-)
> I'm ready to start working on rc3 ...

Oh well, I still have to run at least a few tests with the
enhanced error messages....and there is still more work to
get all messages with source file line numbers, currently
only exceptions have this improvement.

J.Pietschmann



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by Christian Geisert <ch...@isu-gmbh.de>.
Jeremias Maerki schrieb:
> +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. :-)

Actually Jörg proposed a RC in 10-14 days ;-)
I'm ready to start working on rc3 ...

Christian



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by Oleg Tkachenko <ol...@multiconn.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by Jeremias Maerki <de...@greenmail.ch>.
+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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: PDF Encryption: Clarification

Posted by Clay Leeds <cl...@medata.com>.
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 Yahoooooooo! ;-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 - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: 0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by Victor Mote <vi...@outfitr.com>.
Clay Leeds wrote:

> >> 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?
> >
> > http://xml.apache.org/fop/dev/tools.html
>
> I'd seen that before, but now there appears to be <sheepishly>a
> step-by-step there. 'Must've missed it.</sheepishly>

<xsl:template match="sheepishly">
  <blindsided>
    <xsl:value-of select="."/>
  </blindsided>
</xsl:template>

No need to feel sheepish. I added the content last week, but I don't think
it was published until yesterday. I didn't mean to blindside anybody.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by Clay Leeds <cl...@medata.com>.
Christian (& the rest of you FOP folks--pun intended!)

Christian Geisert wrote:
> Well, there's quite some work involved in doing a Release Candidate.
> And a RC - as the name already says - is a kind of preview for the
> actual release (where the changes from candidate to release should
> be minimal). That's the theory ...

I'm sure that's true, and if there were to be more releases (from the
maintenance branch) after 0.20.5, I'd be all for waiting to make certain
the release is as perfect as possible. However, since 0.20.5 is
purported to be the be all, end all for the maintenance branch, I'd like
to make darn certain there aren't any outstanding issues. The only way I
can think of to do that, is to have more than one release candidate, and
test the bejeebers out of it. Forgive my <rant> here, but I personally
don't even think of 0.20.5rc2 as a valuable release candidate, since it
introduced a significant showstopper or two. I had to stop using it
almost immediately (but not before I spent a few hours and went through
all of *my* code, to see if I'd introduced the problem or it was
0.20.5rc2--it would've been so *easy* to just run 0.20.4/fop.bat as a
test--d'oh!). The fact that 0.20.5rc2 has been languishing for so long
as the "most current" release was frustrating to me.</rant>

As I said earlier, I wouldn't mind seeing a new release candidate ASAP,
so that I can continue testing 0.20.5x. The longer it takes for the next
RC to come out, the longer the wait'll be for 0.20.5 to be released. The
fact that 0.20.5 will be the last hurrah 'til 1.0DR1 actually makes me a
bit nervous. Then again, I haven't seen where 1.0DR1 is, so I don't know
where they are in the progress-bar. (Is there some sort of feature
comparison somewhere between 0.20.5x and 1.0DR1? I guess I could do the
CVS thing and find out...)

> [..]
> 
>> 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?
> 
> http://xml.apache.org/fop/dev/tools.html

I'd seen that before, but now there appears to be <sheepishly>a
step-by-step there. 'Must've missed it.</sheepishly>

Thanks for the help! And for your hard work!
-- 
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by Christian Geisert <ch...@isu-gmbh.de>.
Clay Leeds schrieb:
> 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.

Well, there's quite some work involved in doing a Release Candidate.
And a RC - as the name already says - is a kind of preview for the
actual release (where the changes from candidate to release should
be minimal). That's the theory ...

You are right that we should provide snapshots ("daily builds") for
people who can't/won't use CVS - this is already on my todo list.

[..]

> 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?

http://xml.apache.org/fop/dev/tools.html

Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: 0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by Clay Leeds <cl...@medata.com>.
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 - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

0.20.5rc3 (was Re: PDF Encryption: Clarification)

Posted by Christian Geisert <ch...@isu-gmbh.de>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: PDF Encryption: Clarification

Posted by "J.Pietschmann" <j3...@yahoo.de>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: PDF Encryption: Clarification

Posted by Jeremias Maerki <de...@greenmail.ch>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: PDF Encryption: Clarification

Posted by Jeremias Maerki <de...@greenmail.ch>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: PDF Encryption: Clarification

Posted by "J.Pietschmann" <j3...@yahoo.de>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: PDF Encryption: Clarification

Posted by Jeremias Maerki <de...@greenmail.ch>.
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:dev.jeremias@greenmail.ch]
> Sent: Friday, March 14, 2003 4:13 AM
> To: fop-dev@xml.apache.org
> 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: PDF Encryption: Clarification

Posted by "Patrick C. Lankswert" <PL...@InsightBB.COM>.
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:dev.jeremias@greenmail.ch]
Sent: Friday, March 14, 2003 4:13 AM
To: fop-dev@xml.apache.org
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org