Am 24.04.2015 um 22:39 schrieb Thomas Chojecki:
Zitat von Tilman Hausherr <[email protected]>:
Hi Thomas,
Hi Tilman,
1.
I didn't get any feedback whether my change was OK - I'll assume it is.
I did not tested your changes yet, but the VisualSignatureParser
wasn't needed and I as you did in your commit, I also replaced the
VisualSignatureParser with the PDFParser and it works. So no problem
here.
Ok, thanks.
2.
I just did another thing, I moved COSFilterInputStream to
org.apache.pdfbox.pdmodel.interactive.digitalsignature, as it is only
used there, and because SonarQube complains about a package cycle. I
doubt this class is to be used by the public (there's no javadoc), so
I've made it package-non public. If this isn't OK, please protest ASAP.
I use it inside the pdfbox-crypto project :-) It is a kind of
RangedInputstream and can be used to extract the signature and the
content. So it is useful.
Ok, I have reverted that and set it back to public. So you only have to
adjust your import to the new package
org.apache.pdfbox.pdmodel.interactive.digitalsignature.
3.
In PDDocument.prepareNonVisibleSignature() there is this line:
apsStream.createUnfilteredStream();
was the purpose to create an empty stream? I'm asking because the
stream isn't closed, so this might lead to unintended effects if you
do mass signing.
Good question. I think you're right. APS sounds like Appearance
Dictionary Stream and for invisible signatures IMO it should exist and
be empty.
I found a document at [1] that explain the AP in 2.4 with the words:
"... The visual appearance must also exist for an invisible signature
but may be empty. ...". So this is exactly what it does here. But your
right, the stream should be closed.
fixed, thanks!
Tilman
[1]
http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-141.pdf
Tilman
Best regards
Thomas
Am 20.04.2015 um 13:00 schrieb Thomas Chojecki:
Hi Tilman,
I tried yesterday to understand why there was the need for a
VisualSignatureParser and there is no one. I've ran several visual
signature tests today and it make no differents between the
VisualSignatureParser and the PDFParser. So this part can be
replaced refactored.
Did you want to fix this?
Best regards
Thomas
PS: In the other mail you said that there are some getItem() calls
instead of getDictionaryObject() calls. I think I didn't know it
better 6 years ago, so I've used getItem(). So this can be also
fixed. Also the twice call can be removed.
And yes the code is some kind of messy at some points and need to be
cleaned up. I planed some time ago to refactor the code but it would
make sense to refactor the COSWriter first. For signatures / real
incremental updates a List / Set based writer would be a better
solution. The recursive parser has to many restrictions so there is
some kind of hacking in the signature implementations that does not
make sense.
Zitat von Tilman Hausherr <[email protected]>:
Hi Thomas,
Why is the VisualSignatureParser needed, i.e. why can't we just use
the COSParser (and maybe add a method setVisualSignature(File
pdf))? My question is related to the question "parseCOSStream
defined twice" by Andrea Vacondio. There are two calls of the
sequential version; the one in PDFStreamParser I will remove soon
because streams don't exist in content streams, the other one is in
VisualSignatureParser.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
