Hi Thomas. Thank you for the reply.
30 0 obj is at offset "0003029724 00000 n"
The file is fine - I think there is a mopier which scans the documents like this, but I don't see anything wrong with the file.
I have done a lot of debugging of the PDFSharp code, and I came to the conclusion that it is using the xref offset directly, rather than to account for the 1-indexing. I have illustrated this below:
Current mappings (xref)
Code:
2 0 R -> 0000000009 00000 n
3 0 R -> 0000127162 00000 n
4 0 R -> 0000127259 00000 n
5 0 R -> 0003029559 00000 n
.
.
.
29 0 R -> 0003029369 00000 n
30 0 R -> 0003029672 00000 n
31 0 R -> 0003029724 00000 n
But it should be
Code:
1 0 R -> 0000000009 00000 n
2 0 R -> 0000127162 00000 n
3 0 R -> 0000127259 00000 n
4 0 R -> 0003029559 00000 n
.
.
.
28 0 R -> 0003029369 00000 n
29 0 R -> 0003029672 00000 n
30 0 R -> 0003029724 00000 n
Because byte offset 1 is the zero (free) object.
So perhaps there is a hard-coded 0 in the PDFSharp library, which assumes the xref range to be 0-x? Or is it a problem with the PDF document?
If I change the xref to 0 30 then I get an error "Unexpected token 'n' in PDF stream. The file may be corrupted." If I change the Root to 28 0 R and the Info to 29 0 R I get the correct information in those fields, but the incorrect object IDs.