Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.3.3
-
Fix Version/s: 5.0.1
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:ICEpdf 4.3.3 PRO
-
Salesforce Case Reference:
Description
Attached image produces an NPE exception similar to the following:
Exception in thread "main" java.lang.NullPointerException
at org.icepdf.core.pobjects.Document.getPageImage(Document.java:1063)
I did some debugging and found that statements:
Document document = new Document();
document.setFile(filePath);
create a new document object, but getNumberOfPages() method of this object always return zero. Furthermore an exception is thrown when the following line executed thereafter:
int number = document.getNumberOfPages();
BufferedImage image = (BufferedImage) document.getPageImage( number, GraphicsRenderingHints.SCREEN, Page.BOUNDARY_CROPBOX, rotation, scale); <<< NPE thrown at this line
Exception in thread "main" java.lang.NullPointerException
at org.icepdf.core.pobjects.Document.getPageImage(Document.java:1063)
I did some debugging and found that statements:
Document document = new Document();
document.setFile(filePath);
create a new document object, but getNumberOfPages() method of this object always return zero. Furthermore an exception is thrown when the following line executed thereafter:
int number = document.getNumberOfPages();
BufferedImage image = (BufferedImage) document.getPageImage( number, GraphicsRenderingHints.SCREEN, Page.BOUNDARY_CROPBOX, rotation, scale); <<< NPE thrown at this line
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
When parsing the file in question the /pages entry in the catalogue can not be found in the file. The object reference is 4 0 obj and can be easily found via a linear traversal. The xref's for this document are numerous and also take advantage of the object revisions which is quite rare. My guess is that we are not correctly storing the byte offset as we pars from one xref to another.
Show
Patrick Corless
added a comment - When parsing the file in question the /pages entry in the catalogue can not be found in the file. The object reference is 4 0 obj and can be easily found via a linear traversal. The xref's for this document are numerous and also take advantage of the object revisions which is quite rare. My guess is that we are not correctly storing the byte offset as we pars from one xref to another.
The file to reproduce issue has been attached
This appear to be an corner case bug in our CrossReference class. The offending table reads:
xref
1 10
0000000000 65535 f
0000000009 00000 n
0000262316 00000 n
0000262413 00000 n
0000615405 00000 n
0000262600 00000 n
0000615121 00000 n
0000615218 00000 n
0000615469 00000 n
0000615520 00000 n
trailer
<<
/Size 10
/Root 8 0 R
/Info 9 0 R
>>
Our CrossReference class will start counting from 1 on the first entry which is incorrect. The first entry where the generation number is 65535 and free should always be 0. So in effect our implentation will treat
0000000009 00000 n as the second object which is incorrect. As the second object should be a content stream and 0000000009 00000 n is a jpeg.
I've updated our CrossReference parser to take this corner case into consideration and the file renders correctly now.