File fts_05_0502_a4.pdf fails with: GPL Ghostscript SVN PRE-RELEASE 9.00 (2010-07-31) **** Warning: stream operator not terminated by valid EOL. **** Unrecoverable error in xref! Error: /rangecheck in resolveR The file has uncompressed object streams.
Update to reflect customer status and ID.
The sample file cannot be opened by Acrobat 8. xref table points to wrong objects.
Acrobat Reader 9 cannot open the file either.
The Xref stream looks valid. The printable part of this is: 21 0 obj <</Type /XRef /Size 22 /W [1 3 2] /Root 2 0 R /Info 1 0 R /Length 133 /Index [ 0 19 19 3 ] >> stream The /W array is [ 1 3 2 ] and applying this to the stream and printing in hex and annotating by hand gives: 00 000000 ffff % free element list -- next == 000000 means no free list 01 000010 0000 % object 1, offset 0x000010, generation 0000 01 000071 0000 % object 2, offset 0x000071, generation 0000 01 0000ac 0000 % object 3, offset 0x0000ac, generation 0000 01 0000e8 0000 % object 4, offset 0x0000e8, generation 0000 02 000013 0000 % object 5, in compressed stream object 19, index 0 01 000182 0000 % object 6, offset 0x000182, generation 0000 02 000013 0001 % object 7, in compressed stream object 19, index 1 02 000013 0002 % object 8, in compressed stream object 19, index 2 02 000013 0003 % object 9, in compressed stream object 19, index 3 02 000014 0000 % object 10, in compressed stream object 20, index 0 01 0001c4 0000 % object 11, offset 0x0001c4, generation 0000 01 000590 0000 % object 12, offset 0x000590, generation 0000 01 00062c 0000 % object 13, offset 0x00062c, generation 0000 02 000014 0001 % object 14, in compressed stream object 20, index 1 02 000014 0002 % object 15, in compressed stream object 20, index 2 02 000014 0003 % object 16, in compressed stream object 20, index 3 02 000014 0004 % object 17, in compressed stream object 20, index 4 01 000672 0000 % object 18, offset 0x000672, generation 0000 01 000bea 0000 % object 19, offset 0x000bea, generation 0000 <----------- 01 000bea 0000 % object 20, offset 0x000bea, generation 0000 01 000e03 0000 % object 21, offset 0x000e03, generation 0000 This looks, OK, but the object 19 *and* 20 at offset 0x000bea contains: 20 0 obj <</Type /ObjStm /N 5 /Length 433 /First 32 /Extends 19 0 R >> stream 10 0 14 77 15 163 16 244 17 323 <</BaseFont /Times-Bold/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>><</BaseFont /Courier-BoldOblique/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>><</BaseFont /Helvetica-Bold/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>><</BaseFont /Times-Italic/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>><</BaseFont /Times-Roman/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>> endstream endobj The 'Length' of 433 for this stream _does_ point to the 'endstream' which seems correct. The '/N 5' says there are 5 objects contained in the ObjStm, and the '/First 32' specifies that the offset to the first object in the stream is 32, which _does_ get to the "<</BaseFont ..." element for object 10. The other 'objects' in this stream at relative offsets 77, 163, 244 and 323 for objects 14, 15, 16, and 17, respectively, also seem correct. The problem seems to be that the offset for object 19 should be 0x000a42 which points to valid (the Length, First and N entries seem correct) object stream: 19 0 obj <</Type /ObjStm /N 4 /Length 338 /First 21 >> stream 5 0 7 74 8 153 9 229 <</BaseFont /Courier/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>><</BaseFont /Courier-Bold/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>><</BaseFont /Helvetica/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>><</BaseFont /Helvetica-BoldOblique/Encoding /WinAnsiEncoding/Subtype /Type1/Type /Font>> endstream endobj Note that there are some viewers that can handle this (presumably after they repair the error), and if I manually set the address of object 19 in the file to 0x0000a42 and save the file, Adobe Acrobat can open it. I will attach the 'fixed' file. I consider this an INVALID file at this time since the offset to object 19 is clearly broken, so I am downgrading this to a non-customer fix/enhancement. I will inform the customer and Quality Logic of this problem in the test file. The 'fix' part is to be able to process the PDF with the corrected XRef and the 'enhancement' part is to be able to repair the object 21 (XRef) gets the correct offsets in the file.
My testing must not have been correct because HEAD and 8.71 BOTH are able to process the fts_05_0502_fixed.pdf file without errors (also the customer 532 patched version can). I have changed this to a simple 'enhancement' to address the automatic recovery from the bogus object offsets to the compressed ObjStm objects. I will also append this in my comment to Quality Logic, the creator of this file.
Quality Logic has sent us a 'fixed' file and this works now with HEAD.
Changing customer bugs that have been resolved more than a year ago to closed.