I'm working on a toolkit of ours (in Prolog) that generates PDF files
and Adobe Reader and and a PDf repair program both find the PDF
document below incorrect. In my opinion are all the byte offsets and
the crossreference table correct. Has anybody got an idea what's the
problem with the PDF file?
Thank you and with the best regards,
Toine
%PDF-1.4
%êëìí
1 0 obj
<</Type /Catalog
/Pages 3 0 R
/ViewerPreferences <</PrintScaling /AppDefault
/HideToolbar false
/HideMenubar false
>>
>>
endobj
2 0 obj
<</Type /Font
/Subtype /TrueType
/Name /F0
/BaseFont /Courier
/Encoding /WinAnsiEncoding
>>
endobj
3 0 obj
<</Type /Pages
/Kids [5 0 R
]
/Count 1
>>
endobj
4 0 obj
<</Length 157
>>
stream
BT
/F0 11 Tf
1 0 0 1 0 0 Tm
72 630 Td
(This is a line of a PDF document, it's also a very long line that
may be longer than a line2. ) Tj
ET
endstream
endobj
5 0 obj
<</Resources<</Font<</F0 2 0 R
>>
>>
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 595 841 ]
/Contents [4 0 R
]
>>
endobj
xref
0 5
0000000000 65535 f
0000000017 00000 n
0000000166 00000 n
0000000281 00000 n
0000000346 00000 n
0000000560 00000 n
trailer
<</Size 5
/Root 1 0 R
>>
startxref
705
%%EOF
Different operating systems treat line endings differently. As a result
binary files (like PDF) can get mangled when they are inserted into text
newsgroup postings. This makes it difficult to diagnose byte offset
problems.
I did a cut and paste of your posting and fed it into Ghostscript.
Ghostscript also does not like your xref table.
I made the following changes to the end of your file to get it to work.
xref
0 6
0000000000 65535 f
0000000017 00000 n
0000000166 00000 n
0000000281 00000 n
0000000346 00000 n
0000000560 00000 n
trailer
<</Size 6
/Root 1 0 R
>>
startxref
703
%%EOF
The startxref location was changed from 705 to 703. The /Size entry
in your trailer dictionary and the number of entries in the xref table
was changed from 5 to 6. See your copy of the PDF reference for more
details.