JDK-6679904 : JDK6u10 beta on windows: \u200bc not rendered properly in LCD text mode.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_vista
  • CPU: x86
  • Submitted: 2008-03-25
  • Updated: 2010-10-04
  • Resolved: 2008-04-12
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.
6u10 b22Fixed
Related Reports
Relates :  
Relates :  
build 1.6.0_10-beta-b14

Microsoft Windows [Version 6.0.6000]

Java6 update 10 build 13 introduced a font rendering bug as described at http://www.netbeans.org/issues/show_bug.cgi?id=130711

Build 12 rendered this correctly.

This bug can be reproduced always.

Release Regression From : 6u10
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

EVALUATION The root of the problem is that contrary to intentions, the JRE "Lucida Sans" font is being directed to the windows rasteriser in the case when its the fallback font for a JDK logical font (eg monospaced). This is apparent only on systems in which the windows registry font list is missing mappings of the windows XP SP2 "Lucida Sans" fonts. I've seen this happen because the XP SP2 install copies new fonts into \windows\fonts but doesn't update the registry. This is clearly a windows installer, bug but there is nonetheless a JDK problem here. On systems which do have the Lucida font installed, the logical font uses of the windows rasteriser, even though coming from the wrong version of the font are mostly OK since its hard to see the difference. On the systems which don't windows substitutes another font - in this case Arial - and there is no way to find out from windows APIs what font is really being used. It so happens that the character \u200b has the glyphcode 1298 in the JRE's Lucida Sans Regular font, and in Arial that's the glyphcode of \u0416 (Cyrillic capital Zhe with descender). The advance used is however the correct zero-width advance, even though the image is wrong, hence the over-printing with this image. The fix needs to be a more certain way to ensure JRE fonts go through the Java rasteriser.

WORK AROUND Using Windows Explorer open c:\windows\fonts which causes windows to fix its registry, then reboot. That doesn't solve the real JDK problem but makes the obvious problem go away.

EVALUATION So far I haven't been able to reproduce this issue.