PdfTypeException Dictionary value expected.

[richard-domo]

When processing some user-uploaded PDFs, we are seeing the following error in our logs. We are using FDPI v2.6.0

setasign\Fpdi\PdfParser\Type\PdfTypeException
Dictionary value expected.

setasign\Fpdi\PdfParser\Type\PdfTypeException: Dictionary value expected.
#69 /vendor/setasign/fpdi/src/PdfParser/Type/PdfType.php(63): setasign\Fpdi\PdfParser\Type\PdfType::ensureType
#68 /vendor/setasign/fpdi/src/PdfParser/Type/PdfDictionary.php(132): setasign\Fpdi\PdfParser\Type\PdfDictionary::ensure
#67 /vendor/setasign/fpdi/src/PdfParser/Type/PdfDictionary.php(112): setasign\Fpdi\PdfParser\Type\PdfDictionary::get
#66 /vendor/setasign/fpdi/src/PdfReader/PdfReader.php(166): setasign\Fpdi\PdfReader\PdfReader::getPage
#65 /app/Services/Pdfs/Building/PdfBuilder.php(54): App\Services\Pdfs\Building\PdfBuilder::importPage

My colleague created a similar issue a few years back, which can be found here: #129

Is there a recommended way of dealing with this type of exception? I can provide the original PDF for debugging purposes.

[JanSlabon]

This exception is thrown if a data type on the PDF is not of the correct type and the PDF seems to be faulty/invalid.

Feel free to send the PDF in question to support@setasign.com.

PS: Please also upgrade to the latest version.

[gavin310]

@JanSlabon just wanted to comment that we just started having this issue today in a system that's been running smoothly for a couple years now. The PDFs are auto-generated, not user uploaded, so nothing has changed with the format of the PDFs. I'm going to upgrade to the new version, but I'm not sure what could've caused this aside from the server software changing.

[JanSlabon]

Feel free to prepare a reproducible test case and share it with support@setasign.com.
Without analyzing the PDF that is imported, it is very hard to say what's going on here.

Still the case for both @richard-domo and @gavin310.

Thanks!

[gavin310]

@JanSlabon Sorry, I gave you incorrect info in my last comment. I forgot the component that was erroring does allow external PDFs to be included. I'm going to email you the PDF that causes the error. Keep in mind we use a custom class that extends the Fpdi class. The following functions are extended: SetFontSpacing, GetStringWidth, importPage, and useTemplate. I don't believe any of these functions are causing the error but wanted to note them.

[JanSlabon]

@gavin310 The file you send works without a problem. Please prepare a complete test-case that let us reproduce the problem.

Thanks!

[richard-domo]

Thanks for your explanation @JanSlabon, unfortunately the owner of the PDF has asked us not to share it with any third parties.

I understand there is little else you can do without the PDF, so I am happy for this issue to be closed.

[JanSlabon]

Are you (@gavin310 and @richard-domo) related? Or stumbled both of you into the same issue?

[richard-domo]

No, there is no relation.

We process thousands of user-uploaded PDFs every day, and this error only appears occasionally. As the nature of the product is eSignatures, we are trying to improve the UX for our customers. Some users find that they cannot download the signed PDF once all recipients have signed the documents they have been sent. We know we can handle this better to prevent this from happening in the first place and unrelated to FDPI.

I raised the initial issue because I wanted to see if there was a way to resolve this exception through code.

[JanSlabon]

Okay, maybe @gavin310 can provide a document with which we can reproduce this.

I just checked the code and actually I don't think that we can handle this, because the logic really expect the value to be a dictionary at this place. If it is not a dictionary the page tree is faulty/corrupted.