Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 4.1.1
-
Fix Version/s: 4.2
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:-
-
Workaround Exists:Yes
-
Workaround Description:Remove icepdf-viewer.jar but most are using the viewer.
Description
ALFor.pdf does not render correctly when the JLP Diaper Pin font library is installed. This issue only occurs when the icepdf-viewer.jar is on the classpath. With the JLR Diaper Fonts present the font substitution logging is as follows:
Font Substitution: Found system font: TimesNewRomanPS-BoldMT for named font Times New Roman,Bold
Font Substitution: Found system font: New for named font Times New Roman
Full stack trace attached along with screen shots, PDF, and JLP Diaper Pin fonts which can be found here: http://www.fontspace.com/gorillablu/jlr-diaper-pin.
Font Substitution: Found system font: TimesNewRomanPS-BoldMT for named font Times New Roman,Bold
Font Substitution: Found system font: New for named font Times New Roman
Full stack trace attached along with screen shots, PDF, and JLP Diaper Pin fonts which can be found here: http://www.fontspace.com/gorillablu/jlr-diaper-pin.
I thought it looked pretty good with the new family font, oh well.
The font in question gets stored as "new" as it's name and family which when compared to the lookup name "timesnewroman" produces a hit as the search is indexof based. I think a quick work around to the problem is to insure the fontList is always ordered. The reason the app work OK without the viewer jar is that there is no saving of system font data to map and to disk. The saving randomizes the list which produces mixed results.
When the viewer jar is missing the fonts are always in order and the search work more reliably in for this strange test case. I don't see any major concerns with sorting the fontList values by font name. The side effect is that this corner case is resolved.