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 :  
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