JDK-4924220 : Microsoft Sans Serif (True Type) font is not rendered properly
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,1.4.1,1.4.2,1.4.2_03,5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_98,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2003-09-17
  • Updated: 2005-09-19
  • Resolved: 2005-09-19
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 Availabitlity Release.

To download the current JDK release, click here.
Other JDK 6
5.0u7Fixed 6 b53Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Name: jk109818			Date: 09/17/2003

java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)


Windows Millennium [Version 4.90.3000]

Clarification up front:

"MS Sans Serif" (sserife.fon) is a bitmap font.
Bitmap fonts are not supported by Java2D.

"Microsoft Sans Serif" (micross.ttf) is a true type font.
True type fonts ARE supported by Java2D.


When using the "Microsoft Sans Serif" true type font at
size 8 (Windows) / 11 (Java), certain characters/glyphs
are not rendered properly by the Java2D system.


CMQx89             (PLAIN)
MQUWcoswxy0689,*~  (BOLD)

The rendered glyphs for these characters look noticeably
broken. As this is not Bugzilla, I cannot attach a screenshot
of how they differ from the native rendering supplied by
The correct look can be seen in a native Windows application
such as Wordpad with the font set to "Microsoft Sans Serif",
size 8.


Additional points:

* "Microsoft Sans Serif" is the font used by the Classic theme
 in Windows 2000. At size 8, it also looks identical to the
 old "MS Sans Serif" bitmap font that's been in use since
Windows 95.
 "Microsoft Sans Serif" is what many users still use as their
 default font and without this bug being fixed there's no way
 to properly deploy it in a Swing application.

* Again, this bug is not complaining about bitmap fonts or
  how those are substituted. Therefore, this is NOT a duplicate
  of bug 4640557.

* Bug 4533223 fixed the issue of spaces displaying as dots
  but it did not fix the (other) broken glyphs.

Run the attached test case and compare the output
to the native font rendering that can be seen in
a native Windows app such as Wordpad with the font
set to "Microsoft Sans Serif", size 8.

Expected: Glyphs should be indistinguishable from native

Actual: Glyphs look broken.

This bug can be reproduced always.

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

public class MSFontTest extends JFrame {
  public MSFontTest() {
    JPanel pnl = new JPanel();
    pnl.setLayout(new GridLayout());
    JTextArea textArea1 = new JTextArea();
    textArea1.setFont(new Font("Microsoft Sans Serif", Font.PLAIN, 11));
    textArea1.setText("Microsoft Sans Serif size 8 (Java: 11)\n\nCMQx89");
    pnl.add(new JScrollPane(textArea1));
    JTextArea textArea2 = new JTextArea();
    textArea2.setFont(new Font("Microsoft Sans Serif", Font.BOLD, 11));
    textArea2.setText("Microsoft Sans Serif size 8 (Java: 11)
    pnl.add(new JScrollPane(textArea2));
    setSize(new Dimension(540, 100));
  public static void main(String[] args) {
    new MSFontTest();
---------- END SOURCE ----------
(Incident Review ID: 179626) 

###@###.### 2004-01-15

2 CAP members complains the about distorted text in
Java Control Panel in the About section. Notice the 
"C" and "8" text.

EVALUATION Problem with plain capital C was due to insufficient precision while approximating contour curves. With fix for capital C most of the reported plain glyphs are ok (some were fixed earlier as part of 6282527). The only problem left is capital Q and we forked separate bug (6320262) to track it. Some of reported problems with bold glyphs were also resolved as sideeffect of these changes (e.g. bold 8 or 9). Others are likely to be very different issue (related to algorithmic bolding logic, not to scan conversion). Separate bug (6320271) was filed to keep track of them.

EVALUATION Some of reported glitches were caused by absence of support for smart dropout control that was added by Microsoft to Truetype specification. Implementation of smart dropout was recenly added as part of the fix for 6282527. This resolves some of the glitches reported here - namely, Mx89 of PLAIN 11pt Microsoft Sans Serif are ok now.

EVALUATION These rasterization glitches have several different roots. For plain MS Serif most of glitches are due to usage of simple dropout control method defined in Apple version of Truetype specs. However, Microsoft have extended it and Micorosoft Sans Serif is one of fonts requesting "smart" dropout control which is currently unsupported by java rasterizer. We need to support it.

EVALUATION Name: inR10103 Date: 09/19/2003 These effects are due to our current implementation of scan conversion algorithms (in particular Bresenham line-drawing algorithm). At the moment we always shift by 1 pixel either vertically or horisontaly but we can not shift simultaneosly along both axes. ====================================================================== The problems rendering Microsoft Sans Serif are seen by more users than should be seeing it because the Swing Windows L&F in JDK 5.0 is accidentally picking up this font on Windows 2000 and Windows XP when in fact Swing should be picking up "Tahoma". That Swing bug (5079742) is fixed in mustang EA build 12 (see https://j2se.dev.java.net/files/documents/2396/8905/mustang-b12.html) and more usefully for most users in JDK 5.0 update 2. So once that update is available and used, most users should not see this problem *unless* they have changed their desktop theme and/or fonts, or a developer somehow specified it in their application. That's not to say there aren't also a few problems with Tahoma, but they don't seem as obvious. ###@###.### 2005-1-26 20:50:53 GMT