[Dependency] smalot/pdfparser: Font::getDetails() throws TypeError for PDFs with indirect /Encoding objects (upstream fix available in #822/#823)

[kernie]

Bug Report

Note: This is not a bug in LibreSign itself, but a heads-up about a bug in a vendored dependency that affects LibreSign users.

Summary

When uploading certain PDF files (e.g. PDFs with Type1 fonts where is an indirect object reference), LibreSign throws a fatal error:

This originates in the vendored library at:

Root Cause

The PDF spec (Table 5.11) allows a font's entry to be either a name or an indirect reference to an encoding dictionary (). When it is an indirect reference, tried to cast the to string via , which throws a in PHP 8+ because has no .

The affected PDF is not corrupt — it is valid per the PDF specification.

Upstream Fix

This has been reported and fixed upstream in :

• Issue: Font::getDetails() throws TypeError when Encoding is indirect reference to PDFObject smalot/pdfparser#822
• Pull Request (merged/open): Fix Font::getDetails() TypeError when Encoding is indirect reference to PDFObject smalot/pdfparser#823

The fix adds a type-safe branch in that handles encoding dictionaries by reading the header entry instead of casting to string.

Request

Please update the vendored in to a version that includes the upstream fix (once merged), so that LibreSign users are no longer affected by this error.

Environment

• Nextcloud version: 33.0.5.1
• LibreSign vendored pdfparser commit:
• PHP version: 8.x
• Triggered by: Uploading a EncodingAsIndirectPDFObject.pdf PDF with Type1 fonts using indirect references

Nextcloud Log

Workaround

Until the vendored library is updated, the fix can be applied manually to:
3rdparty/composer/smalot/pdfparser/src/Smalot/PdfParser/Font.php

Replace the Encoding line in getDetails() with:

\$encoding = \$this->has('Encoding') ? \$this->get('Encoding') : null;
if (\$encoding instanceof PDFObject) {
    \$baseEncoding = \$encoding->getHeader()->get('BaseEncoding');
    \$details['Encoding'] = (\$baseEncoding instanceof Element && (string) \$baseEncoding !== '')
        ? (string) \$baseEncoding
        : 'Ansi';
} elseif (\$encoding instanceof Element) {
    \$details['Encoding'] = (string) \$encoding;
} else {
    \$details['Encoding'] = 'Ansi';
}

[vitormattos]

Thanks a lot for your contribution!

Before deciding on the best long-term solution, I would like to do more testing and compare https://github.com/PrinsFrank/pdfparser and https://github.com/smalot/pdfparser. They are different projects, but both can help LibreSign achieve the same goal: extracting the dimensions of all pages in a PDF.

I have contributed to both projects, but I'm still evaluating which one would be the best fit for LibreSign. My plan is to test both libraries against a large collection of PDFs from the pdf.js and veraPDF test suites and compare their ability to successfully parse documents and extract page dimensions.

As a short-term fix, we could adopt the solution from your PR as a patch in LibreSign (this is possible because LibreSign also uses cweagans/composer-patches). However, I first need to finish a large refactoring PR that is currently blocking several other improvements in LibreSign. Once that work is completed, I'll be able to dedicate more attention to this issue.

Thanks again for your contribution. I appreciate the effort, and I hope to revisit this issue and evaluate your proposed fix soon.