Bug 691469 - PDF 1.7 FTS: /rangecheck in resolveR
Summary: PDF 1.7 FTS: /rangecheck in resolveR
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: master
Hardware: PC Linux
: P4 enhancement
Assignee: Alex Cherepanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-18 15:15 UTC by Alex Cherepanov
Modified: 2011-09-18 21:47 UTC (History)
0 users

See Also:
Customer: 532
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Cherepanov 2010-07-18 15:15:56 UTC
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.
Comment 1 Ray Johnston 2010-07-18 18:28:59 UTC
Update to reflect customer status and ID.
Comment 2 Alex Cherepanov 2010-07-18 21:21:04 UTC
The sample file cannot be opened by Acrobat 8.
xref table points to wrong objects.
Comment 3 Alex Cherepanov 2010-07-18 22:02:08 UTC
Acrobat Reader 9 cannot open the file either.
Comment 4 Ray Johnston 2010-07-28 00:16:59 UTC
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.
Comment 6 Ray Johnston 2010-07-28 03:31:06 UTC
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.
Comment 7 Ray Johnston 2010-07-29 17:39:16 UTC
Quality Logic has sent us a 'fixed' file and this works now with HEAD.
Comment 8 Marcos H. Woehrmann 2011-09-18 21:47:30 UTC
Changing customer bugs that have been resolved more than a year ago to closed.