[jira] [Commented] (PDFBOX-4396) Memory leak due to soft reference caching
[ https://issues.apache.org/jira/browse/PDFBOX-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711085#comment-16711085 ] Tilman Hausherr commented on PDFBOX-4396: - I'm wondering why you are using java 10... 9 and 10 were kindof "temporary", so I'm doubt that oracle fixed many bugs there. > Memory leak due to soft reference caching > - > > Key: PDFBOX-4396 > URL: https://issues.apache.org/jira/browse/PDFBOX-4396 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.12 > Environment: JDK10; G1 >Reporter: Ben Manes >Priority: Major > Attachments: #2 - memory leak 2.png, #2 - memory leak.png, memory > leak 2.png, memory leak.png > > > In a heap dump, it appears that DefaultResourceCache is retaining 5.3 GB of > memory due to buffered images (via PDImageXObject). I suspect that G1 is not > collecting soft references across all regions before it out-of-memory errors. > In PDFBOX-4389, I discovered very slow PDDocument#load times due to a JDK10 > I/O bug. Previously I was loading the document to render each page, but this > took 1.5 minutes. To work around that bug I reused the document instance > across pages. This seems to have fail because the pages were cached and not > cleared by the GC. > The DefaultResourceCache does not prune its cache entries when the soft > references are collected. Like WeakHashMap, it should use a ReferenceQueue, > poll it on every access, and prune accordingly. > Thankfully PDDocument#setResourceCache exists. For now I am going to reset > the cache to a new instance after a page has been rendered. The entries > should no longer be reachable and be GC'd more aggressively. If that doesn't > work, I'll either replace the cache (e.g. with Caffeine) or disable it by > setting the instance to null. > I think the desired fix is to prune the DefaultResourceCache and, ideally, > reconsider usage of soft references (as they tend to be poor in practice). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4396) Memory leak due to soft reference caching
[ https://issues.apache.org/jira/browse/PDFBOX-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711074#comment-16711074 ] Tilman Hausherr commented on PDFBOX-4396: - The resource cache is not to be shared across documents. The key is COSObject, i.e. an indirect object number. In a PDF file you see these as "10 0 R", and the objects as "10 0 obj". I don't know what internal comment you mean (you didn't quote it), but there is a weakness somewhere that scratch file buffers are not closed properly and this is done in finalization. There is a JIRA issue on this, e.g. PDFBOX-3388 and PDFBOX-3359. If your problem gets solved by calling gc yourself then it means java is to blame because it should do a gc by itself when memory is too low to allocate new objects. If you can reproduce a scenario that eats up available memory then please share the PDF and the code. > Memory leak due to soft reference caching > - > > Key: PDFBOX-4396 > URL: https://issues.apache.org/jira/browse/PDFBOX-4396 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.12 > Environment: JDK10; G1 >Reporter: Ben Manes >Priority: Major > Attachments: #2 - memory leak 2.png, #2 - memory leak.png, memory > leak 2.png, memory leak.png > > > In a heap dump, it appears that DefaultResourceCache is retaining 5.3 GB of > memory due to buffered images (via PDImageXObject). I suspect that G1 is not > collecting soft references across all regions before it out-of-memory errors. > In PDFBOX-4389, I discovered very slow PDDocument#load times due to a JDK10 > I/O bug. Previously I was loading the document to render each page, but this > took 1.5 minutes. To work around that bug I reused the document instance > across pages. This seems to have fail because the pages were cached and not > cleared by the GC. > The DefaultResourceCache does not prune its cache entries when the soft > references are collected. Like WeakHashMap, it should use a ReferenceQueue, > poll it on every access, and prune accordingly. > Thankfully PDDocument#setResourceCache exists. For now I am going to reset > the cache to a new instance after a page has been rendered. The entries > should no longer be reachable and be GC'd more aggressively. If that doesn't > work, I'll either replace the cache (e.g. with Caffeine) or disable it by > setting the instance to null. > I think the desired fix is to prune the DefaultResourceCache and, ideally, > reconsider usage of soft references (as they tend to be poor in practice). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4396) Memory leak due to soft reference caching
[ https://issues.apache.org/jira/browse/PDFBOX-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710785#comment-16710785 ] Ben Manes commented on PDFBOX-4396: --- The memory problems shifted now to object finalization. The GC has 4gb of java.lang.ref.Finalizer queued up. It is unable to keep up and crashes. The referent is ScratchFileBuffer, which calls close() and involves I/O. This is not closed by PDDocument, as the internal comment indicates that COSStream creates new buffers without closing the old ones. This means there is not a way for an application developer to influence this. It does look like my next step will be to disable caching, reduce the reuse of PDDocument instances, and manually trigger GC. I don't think there is much that I can do and that the library makes assumptions based on small / medium sized documents, which at this scale abuse the garbage collector. For a large document it breaks down badly. Do you see any fixes that I can make to help alleviate the problem? > Memory leak due to soft reference caching > - > > Key: PDFBOX-4396 > URL: https://issues.apache.org/jira/browse/PDFBOX-4396 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.12 > Environment: JDK10; G1 >Reporter: Ben Manes >Priority: Major > Attachments: #2 - memory leak 2.png, #2 - memory leak.png, memory > leak 2.png, memory leak.png > > > In a heap dump, it appears that DefaultResourceCache is retaining 5.3 GB of > memory due to buffered images (via PDImageXObject). I suspect that G1 is not > collecting soft references across all regions before it out-of-memory errors. > In PDFBOX-4389, I discovered very slow PDDocument#load times due to a JDK10 > I/O bug. Previously I was loading the document to render each page, but this > took 1.5 minutes. To work around that bug I reused the document instance > across pages. This seems to have fail because the pages were cached and not > cleared by the GC. > The DefaultResourceCache does not prune its cache entries when the soft > references are collected. Like WeakHashMap, it should use a ReferenceQueue, > poll it on every access, and prune accordingly. > Thankfully PDDocument#setResourceCache exists. For now I am going to reset > the cache to a new instance after a page has been rendered. The entries > should no longer be reachable and be GC'd more aggressively. If that doesn't > work, I'll either replace the cache (e.g. with Caffeine) or disable it by > setting the instance to null. > I think the desired fix is to prune the DefaultResourceCache and, ideally, > reconsider usage of soft references (as they tend to be poor in practice). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4396) Memory leak due to soft reference caching
[ https://issues.apache.org/jira/browse/PDFBOX-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Manes updated PDFBOX-4396: -- Attachment: #2 - memory leak 2.png #2 - memory leak.png > Memory leak due to soft reference caching > - > > Key: PDFBOX-4396 > URL: https://issues.apache.org/jira/browse/PDFBOX-4396 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.12 > Environment: JDK10; G1 >Reporter: Ben Manes >Priority: Major > Attachments: #2 - memory leak 2.png, #2 - memory leak.png, memory > leak 2.png, memory leak.png > > > In a heap dump, it appears that DefaultResourceCache is retaining 5.3 GB of > memory due to buffered images (via PDImageXObject). I suspect that G1 is not > collecting soft references across all regions before it out-of-memory errors. > In PDFBOX-4389, I discovered very slow PDDocument#load times due to a JDK10 > I/O bug. Previously I was loading the document to render each page, but this > took 1.5 minutes. To work around that bug I reused the document instance > across pages. This seems to have fail because the pages were cached and not > cleared by the GC. > The DefaultResourceCache does not prune its cache entries when the soft > references are collected. Like WeakHashMap, it should use a ReferenceQueue, > poll it on every access, and prune accordingly. > Thankfully PDDocument#setResourceCache exists. For now I am going to reset > the cache to a new instance after a page has been rendered. The entries > should no longer be reachable and be GC'd more aggressively. If that doesn't > work, I'll either replace the cache (e.g. with Caffeine) or disable it by > setting the instance to null. > I think the desired fix is to prune the DefaultResourceCache and, ideally, > reconsider usage of soft references (as they tend to be poor in practice). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4397) made enum fromString() less error-prone
[
https://issues.apache.org/jira/browse/PDFBOX-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4397:
Attachment: 60.patch
> made enum fromString() less error-prone
> ---
>
> Key: PDFBOX-4397
> URL: https://issues.apache.org/jira/browse/PDFBOX-4397
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Minor
> Labels: enum
> Fix For: 2.0.14, 3.0.0 PDFBox
>
> Attachments: 60.patch
>
>
> Patch proposed by TorstenF76:
> {quote}This is no major issue, but when I saw it, i could not leave it as it
> was. So many hard coded duplicate strings. Error-prone on new enum values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-4397) made enum fromString() less error-prone
[
https://issues.apache.org/jira/browse/PDFBOX-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr resolved PDFBOX-4397.
-
Resolution: Fixed
> made enum fromString() less error-prone
> ---
>
> Key: PDFBOX-4397
> URL: https://issues.apache.org/jira/browse/PDFBOX-4397
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Minor
> Labels: enum
> Fix For: 2.0.14, 3.0.0 PDFBox
>
> Attachments: 60.patch
>
>
> Patch proposed by TorstenF76:
> {quote}This is no major issue, but when I saw it, i could not leave it as it
> was. So many hard coded duplicate strings. Error-prone on new enum values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4397) made enum fromString() less error-prone
[
https://issues.apache.org/jira/browse/PDFBOX-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4397:
Labels: enum (was: )
> made enum fromString() less error-prone
> ---
>
> Key: PDFBOX-4397
> URL: https://issues.apache.org/jira/browse/PDFBOX-4397
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Minor
> Labels: enum
> Fix For: 2.0.14, 3.0.0 PDFBox
>
> Attachments: 60.patch
>
>
> Patch proposed by TorstenF76:
> {quote}This is no major issue, but when I saw it, i could not leave it as it
> was. So many hard coded duplicate strings. Error-prone on new enum values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4397) made enum fromString() less error-prone
[
https://issues.apache.org/jira/browse/PDFBOX-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710470#comment-16710470
]
ASF subversion and git services commented on PDFBOX-4397:
-
Commit 1848232 from til...@apache.org in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1848232 ]
PDFBOX-4397: avoid duplicate strings
> made enum fromString() less error-prone
> ---
>
> Key: PDFBOX-4397
> URL: https://issues.apache.org/jira/browse/PDFBOX-4397
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Minor
> Fix For: 2.0.14, 3.0.0 PDFBox
>
>
>
> {quote}This is no major issue, but when I saw it, i could not leave it as it
> was. So many hard coded duplicate strings. Error-prone on new enum values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4397) made enum fromString() less error-prone
[
https://issues.apache.org/jira/browse/PDFBOX-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4397:
Description:
Patch proposed by TorstenF76:
{quote}This is no major issue, but when I saw it, i could not leave it as it
was. So many hard coded duplicate strings. Error-prone on new enum values.
{quote}
was:
{quote}This is no major issue, but when I saw it, i could not leave it as it
was. So many hard coded duplicate strings. Error-prone on new enum values.
{quote}
> made enum fromString() less error-prone
> ---
>
> Key: PDFBOX-4397
> URL: https://issues.apache.org/jira/browse/PDFBOX-4397
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Minor
> Labels: enum
> Fix For: 2.0.14, 3.0.0 PDFBox
>
> Attachments: 60.patch
>
>
> Patch proposed by TorstenF76:
> {quote}This is no major issue, but when I saw it, i could not leave it as it
> was. So many hard coded duplicate strings. Error-prone on new enum values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4397) made enum fromString() less error-prone
[
https://issues.apache.org/jira/browse/PDFBOX-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710471#comment-16710471
]
ASF subversion and git services commented on PDFBOX-4397:
-
Commit 1848233 from til...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1848233 ]
PDFBOX-4397: avoid duplicate strings
> made enum fromString() less error-prone
> ---
>
> Key: PDFBOX-4397
> URL: https://issues.apache.org/jira/browse/PDFBOX-4397
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Minor
> Fix For: 2.0.14, 3.0.0 PDFBox
>
>
>
> {quote}This is no major issue, but when I saw it, i could not leave it as it
> was. So many hard coded duplicate strings. Error-prone on new enum values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4396) Memory leak due to soft reference caching
[
https://issues.apache.org/jira/browse/PDFBOX-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710391#comment-16710391
]
Ben Manes commented on PDFBOX-4396:
---
Yes, I agree caching makes sense in general. My case is extreme due to N
thousand page documents from scanned paperwork, taking 3-13 seconds per page
for PdfBox to render into an image. While I'd appreciate better performance,
that's only if it retains stability.
I agree weak references are not a fit here and did not intend to imply
otherwise. My point is that the cache held 430k HashMap.Entry objects where
many might have null values. This can be pruned by using a ReferenceQueue,
something like the below code.
Soft references are problematic and typically chosen because a developer
doesn't know a good size. Instead of a strict limit, the decision is left to
the JVM. The references are in a global cache, so an inexpensive cache might
cause a critical one to be flushed. The collection behavior is GC specific and
the penalty is placed in the critical section of the pause time. Many
collectors are not aggressive, which increases hit rates but the memory
pressure causes full GCs in short intervals. A collector that is aggressive
makes the cache ineffective.
If there is a way to estimate the size, then a bounded cache is preferrable.
This avoids the above problems with the potential of higher hit rates, as LRU
can easily to polluted. See for example [Caffeine's hit
rates|https://github.com/ben-manes/caffeine/wiki/Efficiency] by taking
frequency into account, or our new [research
paper|https://drive.google.com/file/d/1CT2ASkfuG9qVya9Sn8ZUCZjrFSSyjRA_/view?usp=sharing]
for an adapting policy. If the number of entries or weight of an entry can be
estimated then a strong reference cache is typically the preferred approach. If
that is problematic, usually one has to investigate off-heap caching.
So far resetting the ResourceCache has been effective. I could try amortizing
that, e.g. reseting it every N pages, to gain a little better reuse as you
indicated. If I had a better sense of the objects being cached, I would switch
to a Caffeine-backed version for an explicit bound. Can the ResourceCache be
shared across documents or are the entries document specific?
{code:java}
final ReferenceQueue queue;
final Map> cache;
public void put(K key, V value) {
prune();
cache.put(key, new SoftValueReference<>(key, value, queue));
}
public V get(K key) {
prune();
var ref = cache.get(key);
return (ref == null) ? null : ref.get();
}
private void prune() {
Reference ref;
while ((ref = queue.poll()) != null) {
var reference = (SoftValueReference) ref;
cache.remove(ref.getKey());
}
}
static final class SoftValueReference extends SoftReference {
private final K key;
public SoftValueReference(K key, V value, ReferenceQueue queue) {
super(value, queue);
this.key = key;
}
public Object getKey() {
return key;
}
}
{code}
> Memory leak due to soft reference caching
> -
>
> Key: PDFBOX-4396
> URL: https://issues.apache.org/jira/browse/PDFBOX-4396
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 2.0.12
> Environment: JDK10; G1
>Reporter: Ben Manes
>Priority: Major
> Attachments: memory leak 2.png, memory leak.png
>
>
> In a heap dump, it appears that DefaultResourceCache is retaining 5.3 GB of
> memory due to buffered images (via PDImageXObject). I suspect that G1 is not
> collecting soft references across all regions before it out-of-memory errors.
> In PDFBOX-4389, I discovered very slow PDDocument#load times due to a JDK10
> I/O bug. Previously I was loading the document to render each page, but this
> took 1.5 minutes. To work around that bug I reused the document instance
> across pages. This seems to have fail because the pages were cached and not
> cleared by the GC.
> The DefaultResourceCache does not prune its cache entries when the soft
> references are collected. Like WeakHashMap, it should use a ReferenceQueue,
> poll it on every access, and prune accordingly.
> Thankfully PDDocument#setResourceCache exists. For now I am going to reset
> the cache to a new instance after a page has been rendered. The entries
> should no longer be reachable and be GC'd more aggressively. If that doesn't
> work, I'll either replace the cache (e.g. with Caffeine) or disable it by
> setting the instance to null.
> I think the desired fix is to prune the DefaultResourceCache and, ideally,
> reconsider usage of soft references (as they tend to be poor in practice).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail:
[jira] [Updated] (PDFBOX-4397) made enum fromString() less error-prone
[
https://issues.apache.org/jira/browse/PDFBOX-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4397:
Description:
{quote}This is no major issue, but when I saw it, i could not leave it as it
was. So many hard coded duplicate strings. Error-prone on new enum values.
{quote}
was:
https://github.com/apache/pdfbox/pull/60
> made enum fromString() less error-prone
> ---
>
> Key: PDFBOX-4397
> URL: https://issues.apache.org/jira/browse/PDFBOX-4397
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Minor
> Fix For: 2.0.14, 3.0.0 PDFBox
>
>
>
> {quote}This is no major issue, but when I saw it, i could not leave it as it
> was. So many hard coded duplicate strings. Error-prone on new enum values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4397) made enum fromString() less error-prone
Tilman Hausherr created PDFBOX-4397: --- Summary: made enum fromString() less error-prone Key: PDFBOX-4397 URL: https://issues.apache.org/jira/browse/PDFBOX-4397 Project: PDFBox Issue Type: Improvement Affects Versions: 2.0.13 Reporter: Tilman Hausherr Assignee: Tilman Hausherr Fix For: 2.0.14, 3.0.0 PDFBox https://github.com/apache/pdfbox/pull/60 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-4393: Fix Version/s: 2.0.14 > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12, 2.0.13 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Fix For: 2.0.14 > > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-4393: Affects Version/s: 2.0.13 > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12, 2.0.13 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Fix For: 2.0.14 > > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4303) Helv and ZaDb overridden
[
https://issues.apache.org/jira/browse/PDFBOX-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4303:
Fix Version/s: 3.0.0 PDFBox
2.0.14
> Helv and ZaDb overridden
>
>
> Key: PDFBOX-4303
> URL: https://issues.apache.org/jira/browse/PDFBOX-4303
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.11
>Reporter: simon steiner
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 2.0.14, 3.0.0 PDFBox
>
> Attachments: PDFBOX-4303-2.0.12.diff, ReaderModifiedForm.pdf
>
>
> Due to change:
> PDFBOX-3943: create /Helv and /ZaDb entries if they don't exist, regardless
> if /DR existed or not
>
> was working ok in 2.0.7, in 2.0 branch
> PDAcroForm
> verifyOrCreateDefaults():
> is:
> {color:#80}if
> {color}(!defaultResources.getCOSObject().containsKey({color:#008000}"Helv"{color}))
> should be checking key in the font dictionary before calling
> defaultResources.put
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4303) Helv and ZaDb overridden
[
https://issues.apache.org/jira/browse/PDFBOX-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710078#comment-16710078
]
Tilman Hausherr commented on PDFBOX-4303:
-
Yes please, open a new issue and delete that part here (all after
"{color:#33}I am unsure if my observed{color}"). And clarify why this
bothers you. Because the now fixed version will still add Helv and ZaDb.
> Helv and ZaDb overridden
>
>
> Key: PDFBOX-4303
> URL: https://issues.apache.org/jira/browse/PDFBOX-4303
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.11
>Reporter: simon steiner
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: PDFBOX-4303-2.0.12.diff, ReaderModifiedForm.pdf
>
>
> Due to change:
> PDFBOX-3943: create /Helv and /ZaDb entries if they don't exist, regardless
> if /DR existed or not
>
> was working ok in 2.0.7, in 2.0 branch
> PDAcroForm
> verifyOrCreateDefaults():
> is:
> {color:#80}if
> {color}(!defaultResources.getCOSObject().containsKey({color:#008000}"Helv"{color}))
> should be checking key in the font dictionary before calling
> defaultResources.put
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4303) Helv and ZaDb overridden
[
https://issues.apache.org/jira/browse/PDFBOX-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710069#comment-16710069
]
beat weisskopf commented on PDFBOX-4303:
[~tilman] What about the other issue? Should I open a new issue? The call to
getLastSignatureDictionary should not intitialize the AcroForm-DefaultResources
imho.
> Helv and ZaDb overridden
>
>
> Key: PDFBOX-4303
> URL: https://issues.apache.org/jira/browse/PDFBOX-4303
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.11
>Reporter: simon steiner
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: PDFBOX-4303-2.0.12.diff, ReaderModifiedForm.pdf
>
>
> Due to change:
> PDFBOX-3943: create /Helv and /ZaDb entries if they don't exist, regardless
> if /DR existed or not
>
> was working ok in 2.0.7, in 2.0 branch
> PDAcroForm
> verifyOrCreateDefaults():
> is:
> {color:#80}if
> {color}(!defaultResources.getCOSObject().containsKey({color:#008000}"Helv"{color}))
> should be checking key in the font dictionary before calling
> defaultResources.put
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710059#comment-16710059 ] ASF subversion and git services commented on PDFBOX-4393: - Commit 1848212 from til...@apache.org in branch 'pdfbox/trunk' [ https://svn.apache.org/r1848212 ] PDFBOX-4393: mark updated when applicable; check whether font dictionary exists; avoid bug that wrong dictionary was checked for font > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710060#comment-16710060 ] ASF subversion and git services commented on PDFBOX-4393: - Commit 1848213 from til...@apache.org in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1848213 ] PDFBOX-4393: mark updated when applicable; check whether font dictionary exists; avoid bug that wrong dictionary was checked for font > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4303) Helv and ZaDb overridden
[
https://issues.apache.org/jira/browse/PDFBOX-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710053#comment-16710053
]
Tilman Hausherr commented on PDFBOX-4303:
-
LOL I had to look several times before I saw the mistake. I'll fix this as part
of the work in PDFBOX-4393.
> Helv and ZaDb overridden
>
>
> Key: PDFBOX-4303
> URL: https://issues.apache.org/jira/browse/PDFBOX-4303
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.11
>Reporter: simon steiner
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: PDFBOX-4303-2.0.12.diff, ReaderModifiedForm.pdf
>
>
> Due to change:
> PDFBOX-3943: create /Helv and /ZaDb entries if they don't exist, regardless
> if /DR existed or not
>
> was working ok in 2.0.7, in 2.0 branch
> PDAcroForm
> verifyOrCreateDefaults():
> is:
> {color:#80}if
> {color}(!defaultResources.getCOSObject().containsKey({color:#008000}"Helv"{color}))
> should be checking key in the font dictionary before calling
> defaultResources.put
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710051#comment-16710051 ] ASF subversion and git services commented on PDFBOX-4393: - Commit 1848209 from til...@apache.org in branch 'pdfbox/trunk' [ https://svn.apache.org/r1848209 ] PDFBOX-4393: add Helv and ZaDb > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710052#comment-16710052 ] ASF subversion and git services commented on PDFBOX-4393: - Commit 1848210 from til...@apache.org in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1848210 ] PDFBOX-4393: add Helv and ZaDb > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[
https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709979#comment-16709979
]
Tilman Hausherr edited comment on PDFBOX-4393 at 12/5/18 12:03 PM:
---
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);{code}
My new theory is that Adobe didn't like that it added two fonts (Helv and ZaDB)
itself. So WE add them instead. However we do already add them when
creating the AcroForm but didn't set the update mark it which is why my (now
deleted) code no longer worked after I corrected the typo.
was (Author: tilman):
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);{code}
My new theory is that Adobe didn't like that it added these two fonts itself.
So WE add them instead. However we do already add them when creating the
AcroForm but didn't set the update mark it which is why my (now deleted) code
no longer worked after I corrected the typo.
> PDF signature invalid after second interactive field signed
> ---
>
> Key: PDFBOX-4393
> URL: https://issues.apache.org/jira/browse/PDFBOX-4393
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
>Affects Versions: 2.0.12
> Environment: Windows
>Reporter: Martin Klíma
>Priority: Major
> Attachments: image-2018-12-04-11-14-01-586.png,
> image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf,
> streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by
> PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by
> AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf,
> streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf,
> streamserve_test_sig2.pdf, streamserve_test_sig3.pdf,
> streamserve_test_sig3.signed.pdf
>
>
> Hi guys,
> I stumped on the problem with PDFBox and interactive field signing. I have
> PDF generated with OpenText StreamServe with two interactive fields for
> signing. See example 1 (streamserve_test_sig0.pdf) in attachement.
> When I use Adobe Reader I can sign both of the visual fields just fine but
> when I use PDFBox to sign one of this field the following signature is marked
> as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe
> Reader See example 3:
> * streamserve_test_sig3.pdf (signed by PDFBox) - valid
> * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid
> !image-2018-12-04-11-14-01-586.png|width=582,height=269!
>
> Also last example - when it´s signed first by Adobe Reader and then with
> PDFBox the signature seems valid but it says the document was "certified".
> See example 2 (streamserve_test_sig2.pdf)
> !image-2018-12-04-11-14-32-676.png|width=591,height=283!
>
> What could be wrong? When is signed whole document with PDFBox it works just
> fine.
> Thanks for response,
> Martin
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[
https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709979#comment-16709979
]
Tilman Hausherr edited comment on PDFBOX-4393 at 12/5/18 12:03 PM:
---
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);{code}
My new theory is that Adobe didn't like that it added these two fonts itself.
So WE add them instead. However we do already add them when creating the
AcroForm but didn't set the update mark it which is why my (now deleted) code
no longer worked after I corrected the typo.
was (Author: tilman):
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);{code}
My new theory is that Adobe didn't like that it added these two. So we add it
ourselves. However we do already add it when creating the AcroForm but
didn't update it which is why my (now deleted) code no longer worked after I
corrected the typo.
> PDF signature invalid after second interactive field signed
> ---
>
> Key: PDFBOX-4393
> URL: https://issues.apache.org/jira/browse/PDFBOX-4393
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
>Affects Versions: 2.0.12
> Environment: Windows
>Reporter: Martin Klíma
>Priority: Major
> Attachments: image-2018-12-04-11-14-01-586.png,
> image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf,
> streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by
> PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by
> AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf,
> streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf,
> streamserve_test_sig2.pdf, streamserve_test_sig3.pdf,
> streamserve_test_sig3.signed.pdf
>
>
> Hi guys,
> I stumped on the problem with PDFBox and interactive field signing. I have
> PDF generated with OpenText StreamServe with two interactive fields for
> signing. See example 1 (streamserve_test_sig0.pdf) in attachement.
> When I use Adobe Reader I can sign both of the visual fields just fine but
> when I use PDFBox to sign one of this field the following signature is marked
> as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe
> Reader See example 3:
> * streamserve_test_sig3.pdf (signed by PDFBox) - valid
> * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid
> !image-2018-12-04-11-14-01-586.png|width=582,height=269!
>
> Also last example - when it´s signed first by Adobe Reader and then with
> PDFBox the signature seems valid but it says the document was "certified".
> See example 2 (streamserve_test_sig2.pdf)
> !image-2018-12-04-11-14-32-676.png|width=591,height=283!
>
> What could be wrong? When is signed whole document with PDFBox it works just
> fine.
> Thanks for response,
> Martin
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[
https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709979#comment-16709979
]
Tilman Hausherr edited comment on PDFBOX-4393 at 12/5/18 12:03 PM:
---
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);{code}
My new theory is that Adobe didn't like that it added two fonts (Helv and ZaDb)
itself. So WE add them instead. However we do already add them when
creating the AcroForm but didn't set the update mark it which is why my (now
deleted) code no longer worked after I corrected the typo.
was (Author: tilman):
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);{code}
My new theory is that Adobe didn't like that it added two fonts (Helv and ZaDB)
itself. So WE add them instead. However we do already add them when
creating the AcroForm but didn't set the update mark it which is why my (now
deleted) code no longer worked after I corrected the typo.
> PDF signature invalid after second interactive field signed
> ---
>
> Key: PDFBOX-4393
> URL: https://issues.apache.org/jira/browse/PDFBOX-4393
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
>Affects Versions: 2.0.12
> Environment: Windows
>Reporter: Martin Klíma
>Priority: Major
> Attachments: image-2018-12-04-11-14-01-586.png,
> image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf,
> streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by
> PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by
> AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf,
> streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf,
> streamserve_test_sig2.pdf, streamserve_test_sig3.pdf,
> streamserve_test_sig3.signed.pdf
>
>
> Hi guys,
> I stumped on the problem with PDFBox and interactive field signing. I have
> PDF generated with OpenText StreamServe with two interactive fields for
> signing. See example 1 (streamserve_test_sig0.pdf) in attachement.
> When I use Adobe Reader I can sign both of the visual fields just fine but
> when I use PDFBox to sign one of this field the following signature is marked
> as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe
> Reader See example 3:
> * streamserve_test_sig3.pdf (signed by PDFBox) - valid
> * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid
> !image-2018-12-04-11-14-01-586.png|width=582,height=269!
>
> Also last example - when it´s signed first by Adobe Reader and then with
> PDFBox the signature seems valid but it says the document was "certified".
> See example 2 (streamserve_test_sig2.pdf)
> !image-2018-12-04-11-14-32-676.png|width=591,height=283!
>
> What could be wrong? When is signed whole document with PDFBox it works just
> fine.
> Thanks for response,
> Martin
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Issue Comment Deleted] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-4393: Comment: was deleted (was: uh, wait a minute... I just see there's a problem, related to the typo I just corrected.) > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[
https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709979#comment-16709979
]
Tilman Hausherr commented on PDFBOX-4393:
-
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);{code}
My new theory is that Adobe didn't like that it added these two. So we add it
ourselves. However we do already add it when creating the AcroForm but
didn't update it which is why my (now deleted) code no longer worked after I
corrected the typo.
> PDF signature invalid after second interactive field signed
> ---
>
> Key: PDFBOX-4393
> URL: https://issues.apache.org/jira/browse/PDFBOX-4393
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
>Affects Versions: 2.0.12
> Environment: Windows
>Reporter: Martin Klíma
>Priority: Major
> Attachments: image-2018-12-04-11-14-01-586.png,
> image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf,
> streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by
> PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by
> AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf,
> streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf,
> streamserve_test_sig2.pdf, streamserve_test_sig3.pdf,
> streamserve_test_sig3.signed.pdf
>
>
> Hi guys,
> I stumped on the problem with PDFBox and interactive field signing. I have
> PDF generated with OpenText StreamServe with two interactive fields for
> signing. See example 1 (streamserve_test_sig0.pdf) in attachement.
> When I use Adobe Reader I can sign both of the visual fields just fine but
> when I use PDFBox to sign one of this field the following signature is marked
> as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe
> Reader See example 3:
> * streamserve_test_sig3.pdf (signed by PDFBox) - valid
> * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid
> !image-2018-12-04-11-14-01-586.png|width=582,height=269!
>
> Also last example - when it´s signed first by Adobe Reader and then with
> PDFBox the signature seems valid but it says the document was "certified".
> See example 2 (streamserve_test_sig2.pdf)
> !image-2018-12-04-11-14-32-676.png|width=591,height=283!
>
> What could be wrong? When is signed whole document with PDFBox it works just
> fine.
> Thanks for response,
> Martin
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[
https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709958#comment-16709958
]
Tilman Hausherr edited comment on PDFBOX-4393 at 12/5/18 11:59 AM:
---
.. and the theory was wrong. It's two fonts in the Acroform default resources.
See [^streamserve_test_sig0_signed by PDFBoxNEW.pdf] and
[^streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf] .
was (Author: tilman):
.. and the theory was wrong. It's two fonts in the Acroform default resources.
See [^streamserve_test_sig0_signed by PDFBoxNEW.pdf] and
[^streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf] .
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
if (res.getFont(COSName.getPDFName("Helv")) == null)
{
res.add(PDType1Font.HELVETICA);
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);
}
if (res.getFont(COSName.getPDFName("ZaDb")) == null)
{
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.add(PDType1Font.ZAPF_DINGBATS);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);
}
{code}
> PDF signature invalid after second interactive field signed
> ---
>
> Key: PDFBOX-4393
> URL: https://issues.apache.org/jira/browse/PDFBOX-4393
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
>Affects Versions: 2.0.12
> Environment: Windows
>Reporter: Martin Klíma
>Priority: Major
> Attachments: image-2018-12-04-11-14-01-586.png,
> image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf,
> streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by
> PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by
> AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf,
> streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf,
> streamserve_test_sig2.pdf, streamserve_test_sig3.pdf,
> streamserve_test_sig3.signed.pdf
>
>
> Hi guys,
> I stumped on the problem with PDFBox and interactive field signing. I have
> PDF generated with OpenText StreamServe with two interactive fields for
> signing. See example 1 (streamserve_test_sig0.pdf) in attachement.
> When I use Adobe Reader I can sign both of the visual fields just fine but
> when I use PDFBox to sign one of this field the following signature is marked
> as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe
> Reader See example 3:
> * streamserve_test_sig3.pdf (signed by PDFBox) - valid
> * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid
> !image-2018-12-04-11-14-01-586.png|width=582,height=269!
>
> Also last example - when it´s signed first by Adobe Reader and then with
> PDFBox the signature seems valid but it says the document was "certified".
> See example 2 (streamserve_test_sig2.pdf)
> !image-2018-12-04-11-14-32-676.png|width=591,height=283!
>
> What could be wrong? When is signed whole document with PDFBox it works just
> fine.
> Thanks for response,
> Martin
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709961#comment-16709961 ] Tilman Hausherr commented on PDFBOX-4393: - uh, wait a minute... I just see there's a problem, related to the typo I just corrected. > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[
https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709958#comment-16709958
]
Tilman Hausherr edited comment on PDFBOX-4393 at 12/5/18 11:45 AM:
---
.. and the theory was wrong. It's two fonts in the Acroform default resources.
See [^streamserve_test_sig0_signed by PDFBoxNEW.pdf] and
[^streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf] .
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
if (res.getFont(COSName.getPDFName("Helv")) == null)
{
res.add(PDType1Font.HELVETICA);
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);
}
if (res.getFont(COSName.getPDFName("ZaDb")) == null)
{
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.add(PDType1Font.ZAPF_DINGBATS);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);
}
{code}
was (Author: tilman):
.. and the theory was wrong. It's two fonts in the Acroform default resources.
See [^streamserve_test_sig0_signed by PDFBoxNEW.pdf] and
[^streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf] .
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
if (res.getFont(COSName.getPDFName("Helv")) == null)
{
res.add(PDType1Font.HELVETICA);
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);
}
if (res.getFont(COSName.getPDFName("Zadb")) == null)
{
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.add(PDType1Font.ZAPF_DINGBATS);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);
}
{code}
> PDF signature invalid after second interactive field signed
> ---
>
> Key: PDFBOX-4393
> URL: https://issues.apache.org/jira/browse/PDFBOX-4393
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
>Affects Versions: 2.0.12
> Environment: Windows
>Reporter: Martin Klíma
>Priority: Major
> Attachments: image-2018-12-04-11-14-01-586.png,
> image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf,
> streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by
> PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by
> AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf,
> streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf,
> streamserve_test_sig2.pdf, streamserve_test_sig3.pdf,
> streamserve_test_sig3.signed.pdf
>
>
> Hi guys,
> I stumped on the problem with PDFBox and interactive field signing. I have
> PDF generated with OpenText StreamServe with two interactive fields for
> signing. See example 1 (streamserve_test_sig0.pdf) in attachement.
> When I use Adobe Reader I can sign both of the visual fields just fine but
> when I use PDFBox to sign one of this field the following signature is marked
> as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe
> Reader See example 3:
> * streamserve_test_sig3.pdf (signed by PDFBox) - valid
> * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid
> !image-2018-12-04-11-14-01-586.png|width=582,height=269!
>
> Also last example - when it´s signed first by Adobe Reader and then with
> PDFBox the signature seems valid but it says the document was "certified".
> See example 2 (streamserve_test_sig2.pdf)
> !image-2018-12-04-11-14-32-676.png|width=591,height=283!
>
> What could be wrong? When is signed whole document with PDFBox it works just
> fine.
> Thanks for response,
> Martin
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[
https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709958#comment-16709958
]
Tilman Hausherr commented on PDFBOX-4393:
-
.. and the theory was wrong. It's two fonts in the Acroform default resources.
See [^streamserve_test_sig0_signed by PDFBoxNEW.pdf] and
[^streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf] .
Add this code before calling addSignature:
{code:java}
PDResources res = acroForm.getDefaultResources();
if (res.getFont(COSName.getPDFName("Helv")) == null)
{
res.add(PDType1Font.HELVETICA);
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);
}
if (res.getFont(COSName.getPDFName("Zadb")) == null)
{
acroForm.getCOSObject().setNeedToBeUpdated(true);
res.add(PDType1Font.ZAPF_DINGBATS);
res.getCOSObject().setNeedToBeUpdated(true);
res.getCOSObject().getCOSDictionary(COSName.FONT).setNeedToBeUpdated(true);
}
{code}
> PDF signature invalid after second interactive field signed
> ---
>
> Key: PDFBOX-4393
> URL: https://issues.apache.org/jira/browse/PDFBOX-4393
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
>Affects Versions: 2.0.12
> Environment: Windows
>Reporter: Martin Klíma
>Priority: Major
> Attachments: image-2018-12-04-11-14-01-586.png,
> image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf,
> streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by
> PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by
> AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf,
> streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf,
> streamserve_test_sig2.pdf, streamserve_test_sig3.pdf,
> streamserve_test_sig3.signed.pdf
>
>
> Hi guys,
> I stumped on the problem with PDFBox and interactive field signing. I have
> PDF generated with OpenText StreamServe with two interactive fields for
> signing. See example 1 (streamserve_test_sig0.pdf) in attachement.
> When I use Adobe Reader I can sign both of the visual fields just fine but
> when I use PDFBox to sign one of this field the following signature is marked
> as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe
> Reader See example 3:
> * streamserve_test_sig3.pdf (signed by PDFBox) - valid
> * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid
> !image-2018-12-04-11-14-01-586.png|width=582,height=269!
>
> Also last example - when it´s signed first by Adobe Reader and then with
> PDFBox the signature seems valid but it says the document was "certified".
> See example 2 (streamserve_test_sig2.pdf)
> !image-2018-12-04-11-14-32-676.png|width=591,height=283!
>
> What could be wrong? When is signed whole document with PDFBox it works just
> fine.
> Thanks for response,
> Martin
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-4393: Attachment: streamserve_test_sig0_signed by PDFBoxNEW.pdf streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig0_signed by PDFBoxNEW.pdf, > streamserve_test_sig0_signed by PDFBoxNEW_signed by AR.pdf, > streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709907#comment-16709907 ] Tilman Hausherr commented on PDFBOX-4393: - At this time, it is a theory. I'll make a test adding metadata with the AddMetadataFromDocInfo.java example and will report back to you. > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4393) PDF signature invalid after second interactive field signed
[ https://issues.apache.org/jira/browse/PDFBOX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709896#comment-16709896 ] Martin Klíma commented on PDFBOX-4393: -- Hi Tilman, thanks for the answer and quick response! So basically the problem is that the PDF file is missing Adobe Reader metadata, am I right? I will check if other software like FoxitReader will accept this as valid but in the mean time, is there any possibility how to make it work for Adobe Reader? Sadly I don't have acces to Adobe Reader support but most of the clients use this software as default PDF reader. Maybe use some tool to include correct Metadata. I am not expert on this, are the Metadata static? Or they change with content of PDF? If they would be static, it would be probably possible to append them to PDF otherwise it would be necessary to somehow automatically open and save the PDF in Adobe Reader to have them correctly formatted in PDF. > PDF signature invalid after second interactive field signed > --- > > Key: PDFBOX-4393 > URL: https://issues.apache.org/jira/browse/PDFBOX-4393 > Project: PDFBox > Issue Type: Bug > Components: Signing >Affects Versions: 2.0.12 > Environment: Windows >Reporter: Martin Klíma >Priority: Major > Attachments: image-2018-12-04-11-14-01-586.png, > image-2018-12-04-11-14-32-676.png, streamserve_test_sig0.pdf, > streamserve_test_sig0_saved.pdf, streamserve_test_sig0_saved_signed by > PDFBox.pdf, streamserve_test_sig0_saved_signed by PDFBox_then_signed by > AR.pdf, streamserve_test_sig2.pdf, streamserve_test_sig3.pdf, > streamserve_test_sig3.signed.pdf > > > Hi guys, > I stumped on the problem with PDFBox and interactive field signing. I have > PDF generated with OpenText StreamServe with two interactive fields for > signing. See example 1 (streamserve_test_sig0.pdf) in attachement. > When I use Adobe Reader I can sign both of the visual fields just fine but > when I use PDFBox to sign one of this field the following signature is marked > as invalid. Doesn't matter if I use PDFbox or sign it manually with Adobe > Reader See example 3: > * streamserve_test_sig3.pdf (signed by PDFBox) - valid > * streamserve_test_sig3.signed.pdf (signed 2nd by Adobe Reader) - invalid > !image-2018-12-04-11-14-01-586.png|width=582,height=269! > > Also last example - when it´s signed first by Adobe Reader and then with > PDFBox the signature seems valid but it says the document was "certified". > See example 2 (streamserve_test_sig2.pdf) > !image-2018-12-04-11-14-32-676.png|width=591,height=283! > > What could be wrong? When is signed whole document with PDFBox it works just > fine. > Thanks for response, > Martin > > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
