Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0
-
Fix Version/s: 3.1
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:ICEpdf OS
-
ICEsoft Forum Reference:
Description
When the OS version of ICEpdf does font substitution a lot of work is done to derive the font family from the font name. The Font class in Java has a constructor that takes style information which it can used to find a matching system font when available. The fix proposed by Pedro helps with this process and especially with the application of the correct font styles; italic and bold.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Applied the patch more or less as suggested. I did however move some font name utility calls out to a new FontUtil class and updated the FontManager and ofont.Font class appropriately.
There is still some code duplication around FontManager.guessFontSytle() and FontUtil.guestAWTFontStyle. The font manager version is uses a different constant value which has a dependency on how we cache system fonts in the ViewerRI. It would be nice to have only one call here but it would mean introducing a mechanism to invalidate previously created font cache files.
Found several regressions related to this approach. We need to keep the basefont name more or less as is for the java.awt.Font.decode method to work correctly. I've changed the logic font substitution logic slightly so that it will do a round of font searches based on the family names of the fonts with out any style information. Just have to run it though qa to see what the consequences are.
Changes passed QA. marking as resolved.
ICEpdf 3.1.0 has been released, closing issues.
Code contribution from Pedro Rivera