Note: The title reflects the initial hypothesis. The actual root cause is not related to /DA annotation entries or URI strings with unescaped parentheses. The real trigger is bare string values with no preceding /Key in the pdfTeX document info dictionary (PTEX.FullBanner). See the root cause description below.
Expected Behavior
PdfReader.Open(stream, PdfDocumentOpenMode.Modify) and PdfReader.Open(stream, PdfDocumentOpenMode.Import) should successfully open PDF 1.3 files produced by pdfTeX/TeX Live that include a document info dictionary containing bare string values without a preceding /Key name - a pattern pdfTeX has emitted for decades via its PTEX.FullBanner metadata entry.
These files open without error in Adobe Acrobat, Chrome, Edge, and every other PDF reader tested.
Actual Behavior
Both open modes throw PdfReaderException: Name expected. during Parser.ReadDictionary, called from Parser.ReadAllIndirectObjects. The exception is thrown when parsing the document info dictionary, which contains (PTEX.FullBanner) and a following string as bare values with no preceding /Name key:
<< /ModDate (D:20260101120000Z) /Creator (LaTeX with hyperref)
/CreationDate (D:20260101120000Z) (PTEX.FullBanner)
(This is pdfTeX, Version 3.141592653-2.6-1.40.29 \(TeX Live 2026\) kpathsea version 6.4.2)
>>
Per PDF spec §7.3.7, a dictionary entry requires a name key followed by a value. These orphaned strings are non-conforming, but all other readers silently skip them. PdfSharp throws instead.
No option in PdfReaderOptions suppresses this error, so there is no workaround within the library.
Affected versions: 6.2.4 and 7.0.0-preview-1.
Stack trace:
at PdfSharp.Internal.ParserDiagnostics.ThrowParserException(String message)
at PdfSharp.Pdf.IO.Parser.ReadDictionary(PdfDictionary dict, Boolean includeReferences)
at PdfSharp.Pdf.IO.Parser.ReadObjectInternal(...)
at PdfSharp.Pdf.IO.Parser.ReadIndirectObject(...)
at PdfSharp.Pdf.IO.Parser.ReadAllIndirectObjects()
at PdfSharp.Pdf.IO.PdfReader.OpenFromStream(...)
at PdfSharp.Pdf.IO.PdfReader.Open(Stream stream, PdfDocumentOpenMode openMode, PdfReaderOptions options)
Steps to Reproduce the Behavior
using PdfSharp.Pdf.IO;
using var stream = File.OpenRead("reproducer.pdf"); // attached
using var pdf = PdfReader.Open(stream, PdfDocumentOpenMode.Import); // throws: Name expected
The attached reproducer.pdf is a minimal self-contained file (5 objects, ~600 bytes) with no confidential content. It contains a single readable page with descriptive text explaining the bug, and a document info dictionary that matches the exact pdfTeX output pattern.
Suggested fix: When ReadDictionary encounters a token that is not a name where a key is expected, skip to the next / or >> boundary and continue rather than throwing unconditionally. Alternatively, expose a PdfReaderOptions.MalformedDictionaryEntry suppression flag analogous to the existing ReferenceToUndefinedObject option.
reproducer.pdf
Note: The title reflects the initial hypothesis. The actual root cause is not related to /DA annotation entries or URI strings with unescaped parentheses. The real trigger is bare string values with no preceding /Key in the pdfTeX document info dictionary (PTEX.FullBanner). See the root cause description below.
Expected Behavior
PdfReader.Open(stream, PdfDocumentOpenMode.Modify)andPdfReader.Open(stream, PdfDocumentOpenMode.Import)should successfully open PDF 1.3 files produced by pdfTeX/TeX Live that include a document info dictionary containing bare string values without a preceding/Keyname - a pattern pdfTeX has emitted for decades via itsPTEX.FullBannermetadata entry.These files open without error in Adobe Acrobat, Chrome, Edge, and every other PDF reader tested.
Actual Behavior
Both open modes throw
PdfReaderException: Name expected.duringParser.ReadDictionary, called fromParser.ReadAllIndirectObjects. The exception is thrown when parsing the document info dictionary, which contains(PTEX.FullBanner)and a following string as bare values with no preceding/Namekey:Per PDF spec §7.3.7, a dictionary entry requires a name key followed by a value. These orphaned strings are non-conforming, but all other readers silently skip them. PdfSharp throws instead.
No option in
PdfReaderOptionssuppresses this error, so there is no workaround within the library.Affected versions: 6.2.4 and 7.0.0-preview-1.
Stack trace:
Steps to Reproduce the Behavior
The attached
reproducer.pdfis a minimal self-contained file (5 objects, ~600 bytes) with no confidential content. It contains a single readable page with descriptive text explaining the bug, and a document info dictionary that matches the exact pdfTeX output pattern.Suggested fix: When
ReadDictionaryencounters a token that is not a name where a key is expected, skip to the next/or>>boundary and continue rather than throwing unconditionally. Alternatively, expose aPdfReaderOptions.MalformedDictionaryEntrysuppression flag analogous to the existingReferenceToUndefinedObjectoption.reproducer.pdf