Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 6.2.4
-
Fix Version/s: 6.2.5
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:any
-
Support Case References:Support Case 14146:- https://icesoft.my.salesforce.com/5007000001kvPEn
Description
I haven't seen such a malformed file in quite some time. The file is completely missing it's xref table or equivalent. Normally in such a case we do a linear traversal of the file indexing the found objects. But what looks to be happening is that there is a large xml section that isn't compressed which is causing our object parser some grief.
Even the new object parser code I've been working on chokes on this file. Further analysis is needed.
Even the new object parser code I've been working on chokes on this file. Further analysis is needed.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Marking as fixed.
Show
Patrick Corless
added a comment - Marking as fixed.
Further testing and digging around has shown the PDF has xref table but it is compressed. The actual bug is how we handle the predictor value associated with decompression using flateDecode. Typically the predictor value is only associated with png or tiff images streams. However as this PDF shows it perfectly valid for any data.
The bug is because we derive the buffer size from an images number of columns, bits per color and number of components. When dealing with none image streams there values resulted in a zero buffer size and a failure to read the xref table. Adding default values correctly the problem ant he PDF renderings correctly.