fd29bb0c57
Xref offsets are relative to the start of the PDF data, not to the start of the PDF file. This is clear if you look at the other code: - In the XRef's readXRefTable and processXRefTable methods of XRef, the offset of a xref entry is set to the bytes as given by a PDF file. These values are always relative to the start of the PDF file (%PDF-). - The XRef's readXRef method adds the start offset of the stream to Xref entry's offset: "stream.pos = startXRef + stream.start". Clearly, this line assumes that the entry offset excludes the start offset. However, when the PDF is parsed in recovery mode, the xref table is filled with entries whose offset is relative to the start of the stream rather than the PDF file. This is incorrect, and the fix is to subtract the start offset of the stream from the entry's byte offset. The manually created PDF file serves as a regression test. It is a valid PDF, except: - The integer to point to the start of the xref table and the %%EOF trailer are missing. This will activate recovery mode in PDF.js - Some junk was added before the start of the PDF file. This exposes the bad offset bug.
29 lines
565 B
Plaintext
29 lines
565 B
Plaintext
Some junk before the header
|
|
|
|
%PDF-1.1
|
|
1 0 obj
|
|
<</Type/Catalog/Pages 2 0 R>>
|
|
endobj
|
|
2 0 obj
|
|
<</Type/Pages/Count 1/Kids[3 0 R]/MediaBox [0 0 400 50]>>
|
|
endobj
|
|
3 0 obj
|
|
<</Type/Page/Parent 2 0 R/Resources<</Font<</F1<</Type/Font/Subtype/Type1/BaseFont/Arial>>>>>>/Contents 4 0 R>>
|
|
endobj
|
|
4 0 obj
|
|
<</Length 43>>
|
|
stream
|
|
BT/F1 14 Tf 20 20 Td(Missing value for startxref and junk before magic header) Tj ET
|
|
endstream
|
|
endobj
|
|
xref
|
|
0 5
|
|
0000000000 65535 f
|
|
0000000008 00000 n
|
|
0000000054 00000 n
|
|
0000000128 00000 n
|
|
0000000254 00000 n
|
|
trailer
|
|
<</Root 1 0 R/Size 5>>
|
|
startxref
|