I'm not sure if this is a bug as it looks like the generated PDF has an invalid document information dictionary (per PDF 32000-1:2008). All PDF files generated by this particular writer have the same issue. Since the document information dictionary is optional can we extend relaxed validation to ignore this?

More details below:

Version

pdfcpu version
pdfcpu: v0.9.1 dev
commit: 4a2f04f3 (2025-02-02T23:54:24Z)
base  : go1.23.3
config: /Users/bwilson/Library/Application Support/pdfcpu/config.yml

OS Information: macOS 15.2 24C101 arm64

Apologies for any incorrect terminology, I'm not overly familiar with the PDF standard.

The PDF file appears to contain a valid Metadata stream (entry 15), however, it looks like the trailer (entry 17? I'm a little confused as the document has no labeled trailer section) references this Metadata stream as the Document Information Dictionary, which should be a dictionary, not a stream dictionary.

Removing the /Info 15 0 R reference in entry 17 allows the PDF to validate.

Chunk of PDF file showing the issue:

<</Type/Metadata/Length 1126/Subtype/XML>>
stream
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
  ... valid looking XMP XML ...
<?xpacket end="w"?>
endstream
endobj
16 0 obj
<</Metadata 15 0 R/Pages 1 0 R/Outlines 12 0 R/Lang(en)/ViewerPreferences<</DisplayDocTitle true>>/Type/Catalog>>
endobj
17 0 obj
<</ID[<3964323030323937><3964323030323937>]/Root 16 0 R/Length 72/Size 18/Info 15 0 R/W[1 4 2]/Filter/FlateDecode/Type/XRef>>
stream
x<9c>c`^@<82>ÿÿ^Y<81>¤0^C^C<90>bV^DS<8c>º`<8a>Á^MB]<87>^H®^@SL^L^P*^VBí<85>èÛ^@¦XÊ!Ôm0Å*^O¡z!Ôy0ÅÕ^D¦¸Y^X^X^@|w <8d>
endstream
endobj

The document is a blank document, there are no real contents.

Document that fails validation

pdfcpu-sample-pdf.log
pdfcpu-sample-pdf.pdf

Document that passes validation

pdfcpu-sample-pdf.hack.log
pdfcpu-sample-pdf.hack.pdf