Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 4.1.1
-
Fix Version/s: 4.2
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:any
-
Assignee Priority:P1
-
ICEsoft Forum Reference:
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 | |
Files Changed | ||||
MODIFY
/icepdf/trunk/icepdf/core/src/org/icepdf/core/util/ContentParser.java
|
Patrick Corless
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
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.