Description
The PDF reader does not support compressed object streams (/ObjStm, i.e. type-2 cross-reference entries). Any PDF written with a cross-reference stream (/Type /XRef, PDF 1.5+) that stores objects inside object streams fails to read/merge with:
pdf: object <N> not found in xref
Because most modern PDF producers emit object streams by default, this affects a large share of real-world PDFs — not an edge case.
Steps to Reproduce
Take any valid PDF and ensure it uses object streams (most modern tools do this already; to force it):
qpdf --object-streams=generate plain.pdf objstm.pdf
# confirm it uses xref + object streams
grep -a -c '/Type[ ]*/XRef' objstm.pdf # -> 1
grep -a -c '/ObjStm' objstm.pdf # -> 1 (or more)
Then:
data, _ := os.ReadFile("objstm.pdf")
_, err := gpdf.Merge([]gpdf.Source{{Data: data}})
// err: "pdf: source 0: pdf: object <N> not found in xref"
Expected Behavior
The reader should support compressed object streams per the PDF spec (ISO 32000, cross-reference streams §7.5.8 and object streams §7.5.7):
- In
parseXRefEntries, handle type-2 entries: field[1] = object number of the containing /ObjStm, field[2] = index of the object within that stream.
- Add an object-stream reader: given an
/ObjStm object, decode its stream, parse the N header pairs (object number / offset) up to /First, and resolve the requested object from the decompressed body. Caching the parsed /ObjStm avoids re-decoding for sibling objects.
With those two pieces, GetObject resolves type-2 objects and object-stream-based PDFs read and merge correctly.
Actual Behavior
Reading/merging the PDF fails with:
pdf: object <N> not found in xref
The object exists in the file inside a compressed object stream (type-2 xref entry), but the reader ignores type-2 entries so GetObject never finds it. The file is valid and opens fine in macOS Preview.
Go Version
go1.26.4 darwin/arm64
gpdf Version
v1.0.11
PDF Viewer (if relevant)
No response
Description
The PDF reader does not support compressed object streams (
/ObjStm, i.e. type-2 cross-reference entries). Any PDF written with a cross-reference stream (/Type /XRef, PDF 1.5+) that stores objects inside object streams fails to read/merge with:Because most modern PDF producers emit object streams by default, this affects a large share of real-world PDFs — not an edge case.
Steps to Reproduce
Take any valid PDF and ensure it uses object streams (most modern tools do this already; to force it):
Then:
Expected Behavior
The reader should support compressed object streams per the PDF spec (ISO 32000, cross-reference streams §7.5.8 and object streams §7.5.7):
parseXRefEntries, handle type-2 entries:field[1]= object number of the containing/ObjStm,field[2]= index of the object within that stream./ObjStmobject, decode its stream, parse theNheader pairs (object number / offset) up to/First, and resolve the requested object from the decompressed body. Caching the parsed/ObjStmavoids re-decoding for sibling objects.With those two pieces,
GetObjectresolves type-2 objects and object-stream-based PDFs read and merge correctly.Actual Behavior
Reading/merging the PDF fails with:
The object exists in the file inside a compressed object stream (type-2 xref entry), but the reader ignores type-2 entries so
GetObjectnever finds it. The file is valid and opens fine in macOS Preview.Go Version
go1.26.4 darwin/arm64
gpdf Version
v1.0.11
PDF Viewer (if relevant)
No response