Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.0.6_P01
-
Fix Version/s: 5.0.7
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:PRO
-
Support Case References:Support Case #12007 - https://icesoft.my.salesforce.com/5007000000RVZkr
Description
The PDF in question (see support case) contains a few digital signature annotations which contain content stream which refer to font names that are not in the xObjects resource dictionary.
Technically this is a malformed PDF but there are some underlying issue we can correct. The initial font failure occurs because we have some old code that will search the font resource dictionary of the first page for the font name in question. However when the first page is garbage collected subsequent call result in a null pointer which inadvertently turns off the font engine.
I've update our Resources.getFont() call to also check the requested name against the fonts basename value which addresses the initial issue with a null font reference for the given font name.
Technically this is a malformed PDF but there are some underlying issue we can correct. The initial font failure occurs because we have some old code that will search the font resource dictionary of the first page for the font name in question. However when the first page is garbage collected subsequent call result in a null pointer which inadvertently turns off the font engine.
I've update our Resources.getFont() call to also check the requested name against the fonts basename value which addresses the initial issue with a null font reference for the given font name.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Added code protection to avoid turning off the font engine when a named font can't be found. Also added a deep search for a font named resource that uses the font base name to try and correctly for a font name that is not found in the main resource font dictionary.