ICEpdf
  1. ICEpdf
  2. PDF-461

NPE exception with PDF file

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major 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
            1. PDF File
              agency.pdf
              610 kB
              Evgheni Sadovoi

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Evgheni Sadovoi added a comment - - edited

              The file to reproduce issue has been attached

              Show
              Evgheni Sadovoi added a comment - - edited The file to reproduce issue has been attached
              Hide
              Permalink
              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.

              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.
              Hide
              Permalink
              Patrick Corless added a comment -

              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.

              Show
              Patrick Corless added a comment - 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.

                People

                • Assignee:
                  Patrick Corless
                  Reporter:
                  Evgheni Sadovoi
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: