ICEpdf
  1. ICEpdf
  2. PDF-219

Malformed Itext 5 document support

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.1
    • Fix Version/s: 4.2
    • Component/s: Core/Parsing
    • Labels:
      None
    • Environment:
      any

      Description

      The Document in question was encoded with iText 5 and has a couple of inconsistencies that are causing our parser some grief. Need to spend a little time to figure out what we have to do to get the file to render as well as create a few v5 enocode sample documents to see what is going on.

        Activity

        Patrick Corless created issue -
        Patrick Corless made changes -
        Field Original Value New Value
        Salesforce Case []
        Fix Version/s 4.2 [ 10243 ]
        Patrick Corless made changes -
        Salesforce Case []
        Assignee Priority P1
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #23976 Thu Feb 17 06:55:20 MST 2011 patrick.corless PDF-219 added fallback code for a null font which tries to find another font in the document to use.
        Files Changed
        Commit graph MODIFY /icepdf/trunk/icepdf/core/src/org/icepdf/core/util/ContentParser.java
        Hide
        Patrick Corless added a comment -

        The PDF in question contains a XForm object that references the font by the name /T1_6 1. The problem here is that /T1_6 1 can not be resolved in the Xform's resource dictionary or anywhere else in the document.

        The content parser will though a null pointer exception in this case and regardless of the exception has no font to render corresponding text with. The problem appears to be a bug with Itext 5.0.1 or with how the client build the document using iText.

        The only way around this bug is to search the document for a font to substitute. I make the assumption that the first pages resource dictionary will have at least one font and that this font can be used as a valid font substitution for the missing font. It's a big assumption but seems to increase the likely hood that we can render the document.

        Show
        Patrick Corless added a comment - The PDF in question contains a XForm object that references the font by the name /T1_6 1. The problem here is that /T1_6 1 can not be resolved in the Xform's resource dictionary or anywhere else in the document. The content parser will though a null pointer exception in this case and regardless of the exception has no font to render corresponding text with. The problem appears to be a bug with Itext 5.0.1 or with how the client build the document using iText. The only way around this bug is to search the document for a font to substitute. I make the assumption that the first pages resource dictionary will have at least one font and that this font can be used as a valid font substitution for the missing font. It's a big assumption but seems to increase the likely hood that we can render the document.
        Hide
        Patrick Corless added a comment -

        Added fall back code when a null font is encountered which search the first page for a valid font.

        Show
        Patrick Corless added a comment - Added fall back code when a null font is encountered which search the first page for a valid font.
        Patrick Corless made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: