Do you have an issue with a specific file(s)? No
Can you reproduce using one of our samples or online demos? Yes
Are you using the WebViewer server? No
Does the issue only happen on certain browsers? No
Is your issue related to a front-end framework? No
Is your issue related to annotations? Yes
Please give a brief summary of your issue:
Load a PDF inside the webviewer, without breaking pre-existing signatures
I have a pdf containing a valid signature (signed on the backend side via the “PDFTron.NET.x64” Version=“11.1.0” library in the demo environment)
Loading that pdf into the webviewer and downloading it immediately, the pre-existing signature is invalid.
Using PDFTron.NET.x64 without WebViewer we can, given a pdf with a valid signature, add a signature type acrofield and sign it without breaking the pre-existing signature.
Is it possible from the webviewer to add an acrofield without breaking a pre-existing signature?
Please provide a link to a minimal sample where the issue is reproducible:
From your answer I don’t understand how to download, from the webviewer, a previously signed document correctly without breaking the signature.
I add that even in your demo page linked above, if I download a document with a valid signature, then immediately reload the document in the webviewer, the signature is corrupted.
This actually fails on the sample demo for 2 reasons:
The file is not incrementally saved, i.e. instance.UI.downloadPdf({ flags: instance.Core.SaveOptions.INCREMENTAL });
Using the download button doesn’t automatically save the file as incremental, so you will need to set this explicitly.
The sample page will add a watermark to the document, which is considered making a change on the document.
If you use a registered license, the signature should remain valid.
Hello,
I tried to implement your solution, on a webviewer with a valid license, but it doesn’t work
These are my tests
1) Listening to onDocumentLoad() and immediately downloading the document: the pre-existing signature works correctly
saveSettings FLAG doesn’t seems to make differences. I tested no flag, flag INCREMENTAL, or LINEARIZED and i get the same result
2) Listening to onDocumentLoad(), change to editAnnotationView and downloading the document: the pre-existing signature breaks
My Code:
this.instance.Core.documentViewer.addEventListener('documentLoaded', async () => {
this.switchToEditAnnotationsView();
setTimeout(() => {
// CHECK IMAGE - RESULT IF I DOWNLOAD IT WITH SaveOptions.INCREMENTAL
this.instance?.UI.downloadPdf({ flags: this.instance?.Core.SaveOptions.INCREMENTAL});
// CHECK IMAGE - RESULT IF I DOWNLOAD IT WITH SaveOptions.LINEARIZED
// this.instance?.UI.downloadPdf({ flags: this.instance?.Core.SaveOptions.LINEARIZED});
}, 1000);
});
// even manually clicking on data-element="signatureFieldToolGroupButton" I get the same result
switchToEditAnnotationsView() {
const iframeDocument = this.getIframeDocument();
if (iframeDocument) {
const buttonForme = iframeDocument.querySelector('.ribbon-group') as HTMLElement;
buttonForme.click();
const div = iframeDocument.querySelector('.tool-group-button') as HTMLElement;
if (div?.children.length) {
const button = div.children[0] as HTMLElement;
if (button) {
button.click();
button.click();
}
}
}
}
// RESULT IF I DOWNLOAD IT WITH SaveOptions.INCREMENTAL
2) Listening to onDocumentLoad(), change to editAnnotationView and downloading the document: the pre-existing signature breaks
When you switch to this view on WebViewer (form field creation mode), the annotations you see on the document are added as temporary annotations. This would be considered making a change to the document hence breaking the signatures.
Starting from version 11.0, there are no temporary annotations and should not be triggering the annotationChanged events:
Unfortunately, this was a major change that was added to 11.0 and cannot be ported back. I recommend. you not to switch to the formfield creation mode.
