-
Enhancement
-
Resolution: Unresolved
-
P4
-
8u60
-
x86
-
os_x
A DESCRIPTION OF THE REQUEST :
On Mac OS, matching of font styles (PLAIN, BOLD, ITALIC) to installed platform fonts is done only based on PostScript name of the font, which should contain one of predefined suffixes to be recognised as a bold or italic font variation. Fonts which don't follow this naming convention, are not recognised properly by Java runtime, even though OS and native applications determine their style correctly.
The issue can be demonstrated by running the code given below after installing Source Code Pro font (can be downloaded from https://github.com/adobe-fonts/source-code-pro/archive/2.010R-ro/1.030R-it.zip, it's enough to install only SourceCodePro-Regular.otf and SourceCodePro-It.otf from the archive). Font Book application correctly shows installed SourceCodePro-It.otf as having an Italic style, but when the Java program requests to draw text using ITALIC-styled Source Code Pro font, fake italic rendering is produced (derived from regular version of the font).
JUSTIFICATION :
The enhancement will allow to use a wider range of fonts in Java applications on Mac OS.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The expected behaviour: when font of particular style is requested from a given font family and there's an installed font from that family that has that style (based on font properties, not its name, e.g. https://www.microsoft.com/typography/otspec/os2.htm#fss), then that font is returned.
For the sample application that would mean that text rendering in the first line (where Font object is constructed using font family name and style) would match the rendering in the second line (where Font object is constructed using full font name).
ACTUAL -
The actual behaviour: Java runtime fails to find font of requested style and creates a derived font based on 'regular' font version.
As a result, in the sample application, text rendered in the first line has larger italic angle than for the correct rendering shown in the second line.
---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.awt.*;
public class StyleDetectionTest {
public static void main(String[] args) {
SwingUtilities.invokeLater(() -> {
JFrame frame = new JFrame();
frame.add(new MyComponent());
frame.setSize(180, 220);
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
});
}
private static class MyComponent extends JComponent {
@Override
protected void paintComponent(Graphics g) {
g.setFont(new Font("Source Code Pro", Font.ITALIC, 24));
g.drawString("Hello", 50, 50);
g.setFont(new Font("SourceCodePro-It", Font.PLAIN, 24));
g.drawString("Hello", 50, 150);
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
The workaround is to use full font name (PostScript name) to construct Font object, as shown in the sample program, but this workaround is not very feasible for applications that allow users to choose the font family from the list of fonts installed in the system, as required font names should be explicitly hardcoded in applications's code.
On Mac OS, matching of font styles (PLAIN, BOLD, ITALIC) to installed platform fonts is done only based on PostScript name of the font, which should contain one of predefined suffixes to be recognised as a bold or italic font variation. Fonts which don't follow this naming convention, are not recognised properly by Java runtime, even though OS and native applications determine their style correctly.
The issue can be demonstrated by running the code given below after installing Source Code Pro font (can be downloaded from https://github.com/adobe-fonts/source-code-pro/archive/2.010R-ro/1.030R-it.zip, it's enough to install only SourceCodePro-Regular.otf and SourceCodePro-It.otf from the archive). Font Book application correctly shows installed SourceCodePro-It.otf as having an Italic style, but when the Java program requests to draw text using ITALIC-styled Source Code Pro font, fake italic rendering is produced (derived from regular version of the font).
JUSTIFICATION :
The enhancement will allow to use a wider range of fonts in Java applications on Mac OS.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The expected behaviour: when font of particular style is requested from a given font family and there's an installed font from that family that has that style (based on font properties, not its name, e.g. https://www.microsoft.com/typography/otspec/os2.htm#fss), then that font is returned.
For the sample application that would mean that text rendering in the first line (where Font object is constructed using font family name and style) would match the rendering in the second line (where Font object is constructed using full font name).
ACTUAL -
The actual behaviour: Java runtime fails to find font of requested style and creates a derived font based on 'regular' font version.
As a result, in the sample application, text rendered in the first line has larger italic angle than for the correct rendering shown in the second line.
---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.awt.*;
public class StyleDetectionTest {
public static void main(String[] args) {
SwingUtilities.invokeLater(() -> {
JFrame frame = new JFrame();
frame.add(new MyComponent());
frame.setSize(180, 220);
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
});
}
private static class MyComponent extends JComponent {
@Override
protected void paintComponent(Graphics g) {
g.setFont(new Font("Source Code Pro", Font.ITALIC, 24));
g.drawString("Hello", 50, 50);
g.setFont(new Font("SourceCodePro-It", Font.PLAIN, 24));
g.drawString("Hello", 50, 150);
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
The workaround is to use full font name (PostScript name) to construct Font object, as shown in the sample program, but this workaround is not very feasible for applications that allow users to choose the font family from the list of fonts installed in the system, as required font names should be explicitly hardcoded in applications's code.