-
Bug
-
Resolution: Fixed
-
P4
-
7, 8, 9, 10
-
b31
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8208972 | 8u201 | Mario Torre | P4 | Resolved | Fixed | b01 |
JDK-8204962 | 8u192 | Mario Torre | P4 | Resolved | Fixed | b01 |
JDK-8216874 | emb-8u201 | Mario Torre | P4 | Resolved | Fixed | master |
JDK-8238400 | 7u271 | Alexey Ivanov | P4 | Resolved | Fixed | b01 |
During initialisation of the fonts, there is a fixed number of fonts to retrieve that depends on the names defined in FontConfigManager.fontConfigNames.
The native code asks fontconfig the best match for those fonts, but in certain cases, namely when only CFF fonts are installed fontconfig (even in addition to the minimum mandatory Type 1 ones), fontconfig returns the CFF as "best match".
This happens, for example, when requesting a font of type "sans:regular:roman". CFF are valid fonts for fontconfig (and are effectively Type 1 OpenType fonts) so the match is registered, but then the actual set returned by fontconfig contains only CFF fonts that are then discarded, thus causing an array of 0 size for "sans:regular:roman", that later on causes an ArrayIndexOutOfBound when this array is accessed in java code:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
at sun.font.CompositeStrike.getStrikeForSlot(CompositeStrike.java:75)
at sun.font.CompositeStrike.getFontMetrics(CompositeStrike.java:93)
at sun.font.FontDesignMetrics.initMatrixAndMetrics(FontDesignMetrics.java:359)
at sun.font.FontDesignMetrics.<init>(FontDesignMetrics.java:350)
at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:302)
at sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1113)
at javax.swing.JComponent.getFontMetrics(JComponent.java:1626)
at ...
On RHEL 7.4 for example, with STIX fonts and the following fonts:
xorg-x11-fonts-Type1-7.5-9.el7.noarch
stix-fonts-1.1.0-5.el7.noarch
you can see what fc-match -f "sans:regular:roman" -sv returns, which is similar to what the code in the JDK does (output edited):
Pattern has 34 elts (size 48)
family: "STIX"(s)
fontformat: "CFF"(w)
postscriptname: "STIX-Regular"(w)
Pattern has 34 elts (size 48)
family: "Cantarell"(s)
fontformat: "CFF"(w)
postscriptname: "Cantarell-Regular"(w)
Pattern has 34 elts (size 48)
family: "STIX"(s)
fontformat: "CFF"(w)
postscriptname: "STIX-Bold"(w)
Pattern has 34 elts (size 48)
family: "STIX"(s)
fontformat: "CFF"(w)
postscriptname: "STIX-Italic"(w)
Pattern has 34 elts (size 48)
family: "STIX"(s)
fontformat: "CFF"(w)
postscriptname: "STIX-BoldItalic"(w)
The native code asks fontconfig the best match for those fonts, but in certain cases, namely when only CFF fonts are installed fontconfig (even in addition to the minimum mandatory Type 1 ones), fontconfig returns the CFF as "best match".
This happens, for example, when requesting a font of type "sans:regular:roman". CFF are valid fonts for fontconfig (and are effectively Type 1 OpenType fonts) so the match is registered, but then the actual set returned by fontconfig contains only CFF fonts that are then discarded, thus causing an array of 0 size for "sans:regular:roman", that later on causes an ArrayIndexOutOfBound when this array is accessed in java code:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
at sun.font.CompositeStrike.getStrikeForSlot(CompositeStrike.java:75)
at sun.font.CompositeStrike.getFontMetrics(CompositeStrike.java:93)
at sun.font.FontDesignMetrics.initMatrixAndMetrics(FontDesignMetrics.java:359)
at sun.font.FontDesignMetrics.<init>(FontDesignMetrics.java:350)
at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:302)
at sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1113)
at javax.swing.JComponent.getFontMetrics(JComponent.java:1626)
at ...
On RHEL 7.4 for example, with STIX fonts and the following fonts:
xorg-x11-fonts-Type1-7.5-9.el7.noarch
stix-fonts-1.1.0-5.el7.noarch
you can see what fc-match -f "sans:regular:roman" -sv returns, which is similar to what the code in the JDK does (output edited):
Pattern has 34 elts (size 48)
family: "STIX"(s)
fontformat: "CFF"(w)
postscriptname: "STIX-Regular"(w)
Pattern has 34 elts (size 48)
family: "Cantarell"(s)
fontformat: "CFF"(w)
postscriptname: "Cantarell-Regular"(w)
Pattern has 34 elts (size 48)
family: "STIX"(s)
fontformat: "CFF"(w)
postscriptname: "STIX-Bold"(w)
Pattern has 34 elts (size 48)
family: "STIX"(s)
fontformat: "CFF"(w)
postscriptname: "STIX-Italic"(w)
Pattern has 34 elts (size 48)
family: "STIX"(s)
fontformat: "CFF"(w)
postscriptname: "STIX-BoldItalic"(w)
- backported by
-
JDK-8204962 AWT java apps fail to start when some minimal fonts are present
-
- Resolved
-
-
JDK-8208972 AWT java apps fail to start when some minimal fonts are present
-
- Resolved
-
-
JDK-8216874 AWT java apps fail to start when some minimal fonts are present
-
- Resolved
-
-
JDK-8238400 AWT java apps fail to start when some minimal fonts are present
-
- Resolved
-
- duplicates
-
JDK-8233828 Add OpenType CFF support in JDK 7
-
- Closed
-
- relates to
-
JDK-8209672 Oracle JDK 8 equivalent fix for JDK-8188030: AIOOBE in font manager init
-
- Resolved
-
(1 relates to)