JDK-8170913 : Java "1.8.0_112" on Windows 10 displays different characters for EUDCs from ones created in eudcedit.exe.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 8u112,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • CPU: generic
  • Submitted: 2016-12-08
  • Updated: 2017-12-12
  • Resolved: 2017-02-13
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 10 JDK 7 JDK 8 JDK 9
10Fixed 7u181Fixed 8u152Fixed 9 b158Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_112"  both of 32 bit and 64bit have this defect.

java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) Client VM (build 25.112-b15, mixed mode, sharing)

java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.14393]

EXTRA RELEVANT SYSTEM CONFIGURATION :
 Windows 10 Japanese.

A DESCRIPTION OF THE PROBLEM :
Java "1.8.0_111" on WIndows 10 displays EUDCs as resisted.
But Java "1.8.0_112" on WIndows 10 displays different characters for EUDCs instead of  resisted ones.

REGRESSION.  Last worked in version 8u111

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_111"  both of 32 bit and 64bit works as expecting.

java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) Client VM (build 25.111-b14, mixed mode, sharing)

java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
On Windows 10, run "eudcedit", create font glyph EUDC u+E000, u+E001 and u+E002
and save it.

Compile and run attached testcase:
     > javac Java2D_UDC.java
     > java Java2D_UDC
------------------------------------------
import java.awt.*;
import javax.swing.*;

public class Java2D_UDC extends JPanel{

  public static void main(String[] args){

    JFrame frame = new JFrame();

    Java2D_UDC comp = new Java2D_UDC();
    frame.getContentPane().add(comp);

    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setBounds(0, 0, 400, 60);
    frame.setTitle("Font Test");
    frame.setVisible(true);
  }

  public void paintComponent(Graphics g){
    Graphics2D g2d = (Graphics2D)g;
  	
  	Font font = new Font(Font.MONOSPACED, Font.PLAIN, 16);
        g2d.setFont(font);
  
	String testStr="UDC:\uE000\uE001\uE002";
	g2d.drawString(testStr , 5, 20);  	
  }
}

---------- END SOURCE ----------


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
EUDC u+E000, u+E001 and u+E002 are shown as registered ones by  eudcedit.exe.
java version "1.8.0_111" can do it.
ACTUAL -
EUDC u+E000, u+E001 and u+E002 are shown as  different characters from registered ones by eudcedit.exe.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import javax.swing.*;

public class Java2D_UDC extends JPanel{

  public static void main(String[] args){

    JFrame frame = new JFrame();

    Java2D_UDC comp = new Java2D_UDC();
    frame.getContentPane().add(comp);

    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setBounds(0, 0, 400, 60);
    frame.setTitle("Font Test");
    frame.setVisible(true);
  }

  public void paintComponent(Graphics g){
    Graphics2D g2d = (Graphics2D)g;
  	
  	Font font = new Font(Font.MONOSPACED, Font.PLAIN, 16);
        g2d.setFont(font);
  
	String testStr="UDC:\uE000\uE001\uE002";
	g2d.drawString(testStr , 5, 20);  	
  }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use java version "1.8.0_111" or below.


Comments
To reproduce, the system locale must be US English, Japanese, Chinese, or Korean. You can also try other char range: "UDC:\uF000\uF001\uF002"; it could suite better. I managed to reproduce the problem with u+F000 ��� u+F002 chars only.
12-12-2017

Nice to make a back port to 8u-dev
21-02-2017

EUDC chars are generally created using eudcedit.exe (a standard Windows utility, even if it is not a widely known one). It creates \windows\fonts\eudc.tte which has a 3,1 windows CMAP and maps ALL code points in the Unicode Private Use Area. The ones you don't create explicitly are mapped to an invisible glyph (no contours). What this means is that EUDC.TTE will hide all private use glyphs in subsequent fonts in a fall back list. EUDC fonts can also be associated with specific physical fonts, but the system default is the only one that JDK uses. Ultimately if two fonts map the same code point only one is going to be usable in a fall back list and it will depend on the order. Segoe UI Symbol is now used by the JDK to compensate for MS Gothic being installed only if the user takes extra action as of Windows 10. This leads to a clash since Segoe UI Symbol also has a 3,1 CMAP but also maps some code points in the private use area. This is actually not uncommon. Many fonts that I've looked at have some code points mapped there. Unusually it defines chars around E000 which is the start of the private use area and the one that EUDCEDIT.EXE tempts you into using which might account for the clash here. The safest solution is to move the EUDC font up in the list. Yes, it will mask all other private use area fonts but no one can be using these anyway unless they have special knowledge of the font. And unless they also have an EUDC font installed (pretty much means almost no one except for some JA locale users and similar) they will be unaffected. The people who do have an EUDC font clearly want that and will have to live with it masking other code points. A more tricky fix would be to "special case" what is marked as an EUDC font to treat glyphs that have no contour as "missing" in that font so it does not stop you accessing all the rest. If we get a real need for that (like an escalation) we can consider that. But for now moving up the EUDC font is the safest option.
10-02-2017

Well, "duh". That is what I wrote in the eval a month ago !
22-01-2017

Submitter reported the same issue(JDK-8172862) but he has provided the cause of this issue. According to the submitter, Java "1.8.0_112" on WIndows 10 displays different glyph for EUDC from ones registered by eudcedit.exe. Instead of registered glyph, ones from 'Segoe UI Symbol' are displayed. On 1.8.0_112, Segoe UI Symbol has been added as a fallback font in the fontconfig as following from 8u111. ------------------------------------------------- allfonts.symbols=Segoe UI Symbol sequence.fallback=lucida,symbols,\ <==== "symbols," has been added here. chinese-ms950,chinese-hkscs,chinese-ms936,chinese-gb18030,\ filename.Segoe_UI_Symbol=SEGUISYM.TTF ------------------------------------------------ 'Segoe UI Symbol' has glyph in the EUDC area (from U+E000) . So instead using registered ones by users, ones from Segoe UI Symbol are displayed. 'Segoe UI Symbol' should not be included in the fallback font list or EUDC font should have higher priority than 'Segoe UI Symbol'.
16-01-2017

My guess is that this is being hidden fontconfig.properties differs between 8u111 and 8u112 --- > allfonts.symbols=Segoe UI Symbol 239c240 < sequence.fallback=lucida,\ --- > sequence.fallback=lucida,symbols,\ 300a302 > filename.Segoe_UI_Symbol=SEGUISYM.TTF ---- This was added for : 8133309: Some unicode characters do not display any more after upgrading to Windows 10
09-12-2016

does it affect 9?
09-12-2016