Please give a brief summary of your issue:
PDFNet.PDFDoc.createFromFilePath fails with a proper path of a png that was converted into PDF file.
Please describe your issue and provide steps to reproduce it:
Create a png file with a text annotation
Convert the png file to a pdf file
Load the converted pdf file with PDFNet.PDFDoc.createFromFilePath
See the following error:
Assertion failed: (m_eventListeners.find(“message”) != m_eventListeners.cend()), function PostMessage, file …/…/…/Node.js/WorkerInstance.cpp, line 30.
Please provide a link to a minimal sample where the issue is reproducible:
const tempConvertedFile = tmp.fileSync({ postfix: ".pdf" });
if (await PDFNet.Convert.requiresPrinter(tempFile.name)) {
throw new Error(`${path} should be converted using PDFNet printer`);
}
const pdf = await PDFNet.PDFDoc.create();
await pdf.initSecurityHandler();
await PDFNet.Convert.toPdf(pdf, tempFile.name);
await pdf.save(
tempConvertedFile.name,
PDFNet.SDFDoc.SaveOptions.e_linearized
);
let pdfDoc;
if (tempConvertedFile) {
//Error occurs loading file from path
pdfDoc = await PDFNet.PDFDoc.createFromFilePath(
tempConvertedFile.name
);
}
Sorry about the delayed response, we did the same as you gave in the example and we are seeing the same issue as above. Has the way pathing works for createFromFilePath changed in any way?
Hey Ryan, I went and did some additional research and found that the conversion and PDFNet.PDFDoc.createFromFilePath did not actually have any issues. It seemed to be that we had multiple calls of PDFNet.runWithCleanup and PDFNet.shutdown(); for a single file which may have caused an issue when we were working with temporary files.
Is there a general best practice how often we should use PDFNet.shutdown?
We had a function that looks like the following:
const convertToPDF = async (): Promise<FileResult> => {
const tempConvertedFile = await tmpFile({ postfix: ".pdf" });
const run = async () => {
if (await PDFNet.Convert.requiresPrinter(tempFile.path)) {
throw new Error(`${path} should be converted using PDFNet printer`);
}
const pdf = await PDFNet.PDFDoc.create();
await pdf.initSecurityHandler();
await PDFNet.Convert.toPdf(pdf, tempFile.path);
await pdf.save(
tempConvertedFile.path,
PDFNet.SDFDoc.SaveOptions.e_linearized
);
};
await PDFNet.runWithCleanup(run, process.env.PDF_NET_LICENSE);
PDFNet.shutdown();
return tempConvertedFile;
};
And a similar function for Merging Annotations to PDF files and it resulted in calling PDFNet.runWithCleanup and shutdown 3-4 times per file. We were able to solve this issue by limiting the number of calls to those functions
This does give insight into how we should run PDFTron, for the case of multithreading PDFTron (convert and merging multiple instances of PDFTron at a time, there a preferred method of how this should be done? We are guessing this issue might stem from the fact that we are multithreading PDFTron
By multi-threading you mean javascript promises? Or do you mean workers?
If you are sharing a since PDFDoc object/instance across threads then you need to do locking.
Otherwise, if each thread has its own PDFDoc object then there should not be any issues.
If the above does not help, then ideally you could modify one of our samples to reproduce the issue you are encountering (and update us on what the issue is).
We are using a package called p-limit which runs multiple promise-returning & async functions with limited concurrency. I’ll take a look at locking and see if the issue still persists, thank you!
I think we’ve deduced what the issue was, we found that we had to initialize PDFNet for every parallel task and we didnt see the issue occuring anymore, thank you for the documentations above they helped solve the problem. We did this along the lines of