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
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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.
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.