JDK-8078382 : Wrong glyph is displayed for a derived font
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-04-22
  • Updated: 2016-10-13
  • Resolved: 2016-06-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u112Fixed 9 b124Fixed
Related Reports
Relates :  
JDK-8158637 - Change FontFamily.getClosestStyle() for BOLD | ITALIC case
Description
An incorrect glyph is rendered with ���Code New Roman��� font on Windows.
In particular, if bold italic combination is requested, Java renders �� instead of '.
The attached test and screen shots demonstrate the problem.
Comments
I ran a number of tests with different fonts: Windows GDI consistently selects Bold rather than Italic to produce the missing Bold Italic. I used GetFontData and compared the size of the font file on the file system and the size of data returned by GetFontData. I suggest using Andrew's first patch: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ The patch changes the order of font selection: bold will be used, if possible, as the base for bold-italic instead of italic which is the current default. It also fixes the issue where italic is returned instead of bold.
25-04-2016
Phil: yes, you remember it correctly. It might make sense to limit the change to Windows only. However, the selection occurs in shared code sun.font.FontFamily.getFont(int style), see Andrew's webrev above. I don't see an elegant way how we can limit the change to Windows only and hence preserve the previous behavior on other platforms.
12-04-2016
Alexey: correct me if I misremember but when we discussed this it seemed like this situation arises only in the case of requesting "Bold Italic" but none exists and GDI always chooses "Bold" as the base font from which to synthesise whereas JDK chooses "Italic". So we could switch over to choosing the same base font as windows - in as limited a manner as we can reasonably manage. That might mean only on Windows.
11-04-2016
The described situation where a character has different glyph indexes in different font files of the font family is really rare. The complexity of implementing the additional check seems an overkill for such a corner case. As a workaround, when an application needs to render text in 'Code New Roman Bold Italic', it can pass 'Code New Roman Bold' or 'Code New Roman Italic' as the font family to eliminate the ambiguity of selecting the font file to determine the glyph index of the character.
18-11-2015
No regression test because it requires a specific font to be installed on a test system. The font can be found here: http://www.dafont.com/code-new-roman.font
15-07-2015
webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-July/005562.html
15-07-2015
The problem is caused by following peculiarity of the Code New Roman font: this font provides plain, italic and bold variants. In bold and italic variants of the font, different glyphs correspond to the apostrophe character (0039): bold: 0039 -> 0x250 (592) italic: 0039 -> 0x256 (598) So, we translate character to glyphs using italic variant of the font, and then request glyph images from GDI. However, GDI uses the bold variant of the font in order to compose glyph images for artificial bold-italic variant, and we have got a glyph image for �� instead of apostrophe. Suggested fix is to select bold variant (if possible) as a base for artificial bold-italic.
15-07-2015