Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8078382

Wrong glyph is displayed for a derived font

    Details

    • Subcomponent:
      2d
    • Resolved In Build:
      b124

      Backports

        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.
        1. Test.java
          3 kB
          Andrew Brygin
        1. code-new-roman-8u45.png
          18 kB
        2. code-new-roman-fixed.png
          18 kB

          Issue Links

            Activity

            Hide
            bae Andrew Brygin added a comment - - edited
            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.
            Show
            bae Andrew Brygin added a comment - - edited 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.
            Show
            bae Andrew Brygin added a comment - - edited webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-July/005562.html
            Hide
            bae Andrew Brygin added a comment -
             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
            Show
            bae Andrew Brygin added a comment -  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
            Hide
            aivanov Alexey Ivanov added a comment -
            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.
            Show
            aivanov Alexey Ivanov added a comment - 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.
            Hide
            prr Philip Race added a comment -
            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.
            Show
            prr Philip Race added a comment - 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.
            Hide
            aivanov Alexey Ivanov added a comment -
            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.
            Show
            aivanov Alexey Ivanov added a comment - 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.
            Hide
            aivanov Alexey Ivanov added a comment -
            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.
            Show
            aivanov Alexey Ivanov added a comment - 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.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b803887ddddc
            User: aivanov
            Date: 2016-06-02 12:37:29 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b803887ddddc User: aivanov Date: 2016-06-02 12:37:29 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b803887ddddc
            User: lana
            Date: 2016-06-22 19:53:10 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b803887ddddc User: lana Date: 2016-06-22 19:53:10 +0000

              People

              • Assignee:
                aivanov Alexey Ivanov
                Reporter:
                shadowbug Shadow Bug
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: