The necessary conditions to reproduce the problem on the customer´s Windows XP SP3 and Windows 7 are:

1) Install the JLR Diaper Pin font in the Windows fonts directory.

2) Run the attached sample code including icepdf-core.jar, icepdf-pro.jar, icepdf-pro-intl.jar, and icepdf-viewer.jar in the classpath.

As you stated, removing the icepdf-viewer.jar from the classpath fixes the problem, but this is not an option for us.

The example in the test case folder does not have any references to icepdf-viewer.jar and helped narrow down the cause of the problem. The test case zip also has the PDF.

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.