Memory leak when using pdfView to print to file

Hi, I hope you can help.

I’m trying to find a work around to the PDF flattening issue identified in PDFNET-54570.

The work around is to use pdfView to convert PDF XFA forms to a PDF Image file using the "“Microsoft Print to PDF” printer.

Two issues were discovered when I try this method:

  1. With our Adobe Designer 7.0 PDF forms. There is a significant memory leak each time pdfView is used. This leak doesn’t occur with a test file I pulled from your sample code. I’ve tried to identify where the differences are by changing encryption settings, document versions and other variable but can’t stop the leak.

  2. The second issue is that when I print the PDF through the pdfView the digital signatures in the document are lost.

When printing documents from Adobe Acrobat to MS PDF printer. I don’t have either issue.

I’ll attach my test program and the sample files I used.
pdfViewTests.zip (658.6 KB)

@catpus

Can you please share your environment details as well like OS Name and Version, installed RAM Size, etc.? Also, if possible, please share a screenshot of the stats how Diagnostic Tool of Visual Studio shows memory consumption/leak in your environment? We will further proceed to assist you accordingly.

I have observed this behavior on my workstation and on our test server.
Workstation: Windows 10 build 19045, 14 core, with 32 GB of RAM
Development Server: Windows Server 2016, 2 vCPU, 8 GB or RAM

In both cases testing was done via the console application that I sent you, and web API’s running on IIS.

The application and API both use dotNet 8 and the latest ASPOSE nugget packages.

Postman was used to send calls to the API’s. Sysinternals Process Explorer was used to monitor the memory growth. Memory utilization was also monitored using the Windows Task Manager Resource Monitor

ProcExp link: Process Explorer - Sysinternals | Microsoft Learn

The first round of testing was done using the DMS-t1.pdf file that can be found in the resource folder of the zip file I sent you. The file was created using Adobe LiveCycle Designer 11.0. The second round of testing was done using the DynamicXFAToAcroForm.pdf provided in ASPOSE’s Aspose.PDF-for-Net code repository. There is some increase in the memory consumption but not significant. The screenshots are in the attached Word document.
Testing with DMS.docx (359.3 KB)

@catpus

At the moment, .NET 8.0 support needs to be investigated as well as we have been working on developing new engine to process documents with XFA which is not yet finalized.

Therefore, we have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): PDFNET-56446

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

The issue also exists with .NET 6.0. Do you have a rough idea when the new XFA engine will be released?

@catpus

The ticket has been logged recently under the free support model and it will be prioritized on a first come first serve basis. As soon as we make some progress towards its resolution, we will let you know. Please be patient and spare us some time.

We are sorry for the inconvenience.

That wasn’t really my question. You mentioned that the XFA engine is being rewritten. I was wondering if you have a release date for the new engine.

@catpus

We are sorry that we overlooked the real question. About new XFA engine, the work is still ongoing parallel to the other tasks we have. Unfortunately, no promising ETA can be provided at the moment as many API components need to be revised. However, as soon as we have some definite updates about its ETA, we will share with you in this forum thread.