[gs-bugs] [Bug 691469] PDF 1.7 FTS: /rangecheck in resolveR

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Wed Jul 28 00:17:00 UTC 2010


http://bugs.ghostscript.com/show_bug.cgi?id=691469

Ray Johnston <ray.johnston at artifex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--- Comment #4 from Ray Johnston <ray.johnston at artifex.com> 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.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list