Issue with PreSigned PDF in WebViewer

kkim · March 11, 2025, 5:30pm

Hi there,

This item is currently being refined by the development/product team and we will let you know when we have further updates.

best regards,
Kevin

kkim · April 7, 2025, 1:55pm

Hi there,

We’ve now fixed this issue and it’s available in our latest nightly experimental build. See here for instructions on how to try out the nightly build Where can I find WebViewer nightly builds? | Apryse documentation
Let us know if it’s working for you.

This fix will be available in our next official release.
You can keep an eye out for when our new release is available: Announcements - Apryse Community and the change-logs: Version 11.3.0 Changelog (2025-02-19) | Apryse documentation

best regards,
Kevin

w.bonazzoli · April 15, 2025, 1:13pm

Hi Kevin,

Thank you for your continued support.

We have just tested the issue using WebViewer version 11.4, since the nightly build link provided earlier no longer contains a downloadable version.

Test Scenario:

We loaded a PDF with valid digital signatures (permission level 3: e_annotating_formfilling_signing_allowed).
We activated the "toolbarGroup-Forms" to allow adding AcroFields.
We downloaded the PDF using SaveOptions.INCREMENTAL.
We opened the resulting file in Adobe Acrobat.

Result:

The pre-existing signatures are still shown as invalid in Adobe Acrobat.
This happens even without making any actual changes to the form — simply switching to form editing mode appears to alter the document structure.

Summary:

Although we’re now on the latest official release (11.4), the issue persists. Our key requirement remains:

Allow users to add new AcroFields without invalidating existing digital signatures.
Ensure full compatibility with Adobe Acrobat and other standard PDF viewers.

Could you please confirm:

Whether this fix was included in 11.4?
If there’s any specific configuration or usage pattern we might be missing?

Looking forward to your feedback — this is a critical blocker for us.

Best regards,
William

kkim · April 21, 2025, 2:49pm

Hi there,

Thank you for your response,

Just to make sure, could you please try the latest experimental build to confirm that the fix is in?
It is available in our nightly page here:
https://dev.apryse.com/nightly/
Today’s date can be found here:
https://dev.apryse.com/nightly/experimental/2025-04-21/webviewer

I was able to see that the release version of 11.4 does not have the fix, I will confirm with the development team to see if it is possible to push this fix into the 11.4 build.

Best regards,
Kevin

w.bonazzoli · April 22, 2025, 12:21pm

Hi Kevin,

Thanks for your reply.

As suggested, I installed the latest nightly build using:

npm install @pdftron/webviewer@11.5-nightly

However, after testing it with the sample document (attached), the issue still persists. Specifically, when entering form mode and then downloading the document with the incremental flag enabled, the electronic signature breaks again.

So unfortunately, it looks like the bug is still not resolved in the nightly build.

Nightly version: 11.5.0-20250422
tiger_withApprovalField_certified_approved_ORIGINAL.pdf (51.1 KB)

Best regards,
William

kkim · April 22, 2025, 9:05pm

Thank you for your response,

I also tested with the @pdftron/webviewer@11.5-nightly tag and it only updates the .min.js file and thus may be missing the fix.

Using the above zipped package from the nightly link (Apryse Developer Portal) I can see that the signature is no longer broken on entering the form mode and leaving (without making any changes to the fields themselves)

Please try the zipped package a try and let me know if that works for you.
Alternatively, you can specify the date during the installation:
“@pdftron/webviewer”: “11.5.0-20250422”,

Best regards,
Kevin

kkim · April 22, 2025, 9:06pm

To follow up on the 11.4 request, unfortunately this fix is complex and can not be trivially pushed to version 11.4.

This fix however, will be available in our May maintenance release.

best regards,
Kevin

w.bonazzoli · April 23, 2025, 2:56pm

Hi Kevin,

Thank you for your continued support.

I’ve tried installing both versions you mentioned using:

npm install @pdftron/webviewer@11.5.0-20250421

and

npm install @pdftron/webviewer@11.5.0-20250422

Unfortunately, both versions are causing issues on my end.

As for the zipped package from the nightly link, I tried to integrate it manually by copying and replacing the files inside node_modules, but I’m encountering problems — specifically, TypeScript throws the following error:

'type.d.ts' is not a module

It seems that the types are not properly exported or recognized in this patched version. As I’m working with Angular, could you please advise how to correctly install and use this patched version in an Angular environment? If there’s a more appropriate integration method for Angular, I’d really appreciate your guidance.

Alternatively, if you have a working sample Angular app using this nightly build (including the patched files), that would be extremely helpful for us to move forward.

Thanks again — looking forward to your help on this!

Best regards,
William

kkim · April 23, 2025, 5:52pm

Hi there,

Could you please try the following steps:

Download the Angular sample available here:
webviewer-samples/webviewer-angular at main · ApryseSDK/webviewer-samples · GitHub
Change the package.json to specify @pdftron/webviewer to use

    "@pdftron/webviewer": "11.5.0-20250422",

Change the WebViewer constructor inside webviewer.component.ts file to add file picker, remove initial doc, and use a valid license:

  ngAfterViewInit(): void {
    WebViewer({
      path: '../../lib/webviewer',
       licenseKey: 'enter valid license key here', 
      // initialDoc: '/files/WebviewerDemoDoc.pdf'
      enableFilePicker: true,
    }, this.viewer.nativeElement).then(instance => {

run the application via npm i && npm run start
Use the top left settings and open the original file, go to forms mode, and then go to view mode
Download the document via incremental save:
instance.UI.downloadPdf({ flags: instance.Core.SaveOptions.INCREMENTAL });
Load the saved document on Adobe - it should be the same as before loading it on WebViewer

Here is a quick video for reference: Screen Recording 2025-04-23 at 1.44.47 PM.mov

best regards,
Kevin

w.bonazzoli · April 24, 2025, 1:53pm

Hi Kevin,

I was able to successfully reproduce the working example you provided—thank you for the detailed guidance.

However, I’ve noticed that when I enable the multitab feature using:

this.instance.UI.enableFeatures([this.instance.UI.Feature.MultiTab]);

even with just a single document loaded, the signature appears to break. It seems enabling MultiTab is impacting signature rendering or behavior somehow.

This feature is essential for our use case, so we’d really appreciate any insights or workarounds you might be able to share in the meantime.

Looking forward to your thoughts, and thanks again for your continued support.

Best regards,
William

kkim · April 24, 2025, 7:07pm

Thank you for your response,

It looks like enabling and loading the document in MultiTab mode also breaks the signatures. I will raise this as another bug and will let you know when we have additional information or updates.

Best regards,
Kevin

w.bonazzoli · April 28, 2025, 8:46am

Hi Kevin,

Thanks for your feedback — we will wait for updates regarding the MultiTab issue.

In the meantime, we’d like to take this opportunity to ask about another behavior we encountered:
when we load a signed PDF and apply the following settings to annotations:

private async lockAnnotationsAndFields(): Promise<void> {
    const { annotationManager } = this.instance!.Core;

    const annots = annotationManager.getAnnotationsList();

    annots.forEach((annot: any) => {
        annot.ReadOnly = true;
        annot.Locked = true;
        annot.NoMove = true;
        annot.NoResize = true;
        annot.Listable = false;
    });
}

after switching to the “Forms” view, all annotations on the PDF become invisible.

Our goal is to make already signed fields unmodifiable without invalidating the existing signatures.
At the same time, we would like the previously signed fields — as well as any other form fields — to remain visible even after switching to the Forms panel.

Could you help us understand why the annotations disappear and suggest the correct approach to achieve this?

I’m also attaching screenshots showing the document before and after switching to the Forms view for your reference.

Thanks again for your valuable support — we look forward to hearing from you.

Best regards,
William

kkim · April 28, 2025, 2:31pm

Hi there,

Setting the annotation’s Listable property false means they will no longer show up in the notesPanel. However, I can see the same annotations when loading it to the Forms mode on the showcase using the same document provided.

Are you using a different version of WebViewer? Can you reproduce this on the showcase?

best regards,
Kevin

w.bonazzoli · April 30, 2025, 6:55am

Hi Kevin,

Thanks for the clarification, you’re right: after testing it directly in your sample project, the annotations do appear correctly in Forms mode, even with Listable set to false.
So it seems the issue might be specific to our implementation, we’ll investigate further on our side.

In the meantime, do you have any updates regarding the other bug related to the MultiTab feature breaking signatures? That functionality is quite important for us, so we’re eager to know if any fix or workaround is progressing.

Thanks again for your support.

Best regards,
William

kkim · April 30, 2025, 5:09pm

Hi William,

We currently do not have any updates regarding the multiTab feature at this moment.

Best regards,
Kevin

w.bonazzoli · July 11, 2025, 9:34am

Hi Kevin,

Thank you for your continued support on this issue.

I’ve just updated to WebViewer version 11.6, which mentions this bug as resolved in the changelog: Version 11.6.0 Changelog (2025-07-09) | Apryse documentation

However, I’m still experiencing issues with pre-existing signatures being corrupted when downloading documents, even with minimal operations.

Test scenario:

Load a PDF with valid digital signatures (using the same test document: tiger_withApprovalField_certified_approved_ORIGINAL.pdf)
Download the pdf using incremental save, after webviewer initialization
Check the signatures in Adobe Acrobat

Code used:

WebViewer(
            {
                path: './assets/lib',
                licenseKey: environment.apryseKey,
                enableFilePicker: true,
                initialDoc: 'assets/tiger_withApprovalField_certified_approved_ORIGINAL.pdf',
                fullAPI: true,
            },
            this.viewerRef.nativeElement,
        )
            .then((instance2) => {
                instance2.Core.documentViewer.addEventListener('documentLoaded', async () => {
                    setTimeout(() => {
                        instance2?.UI.downloadPdf({ flags: instance2?.Core.SaveOptions.INCREMENTAL });
                    }, 1000);
                });
             })
            .catch((error) => {
                console.error('Failed to initialize WebViewer:', error);
            });
    }

Result: Even with this minimal approach (no form mode activation, no MultiTab feature), the downloaded PDF shows corrupted signatures when opened in Adobe Acrobat.

Questions:

Can you confirm that the fix mentioned in the 11.6 changelog specifically addresses this signature corruption issue?
Are there any additional configuration steps or specific usage patterns required in v11.6 to ensure signature preservation?
Could you test this scenario with the same document on your end using v11.6?

This remains a critical blocker for our production environment, as we need to ensure that any document processing through WebViewer maintains signature integrity for compliance purposes.

I’m attaching:

The original test document (tiger_withApprovalField_certified_approved_ORIGINAL.pdf)
Screenshots showing the corrupted signatures after download
Code snippet used for testing

Looking forward to your guidance on resolving this in v11.6.

Best regards, William

tiger_withApprovalField_certified_approved_ORIGINAL.pdf (51.1 KB)

kkim · July 11, 2025, 4:36pm

Hi there,

I am seeing the same result on the WebViewer 11.6 release version even with minimal changes.

We are looking into this issue and will let you know when we have an update.

Best regards,
Kevin

kkim · July 16, 2025, 7:48pm

Hi there,

A patch was made for this issue:

Could you please give version 11.6.1 a try and let me know how that works for you.

Best regards,
Kevin