Three weeks ago the following RFE was filed in the bug tracker under Java2D team:

Windows Vista introduces the Consolas to replace the Courier font. The new font is a lot easier to read. The JDK should default to using Consolas instead of Courier under Windows Vista. Consolas is easier to read than Courier. Users will expect Java to look like other native applications which will switch over to Consolas over time.

After this RFE has been filed, it has been assigned a very low priority and closed as “will not fix”. The engineer responsible for this RFE found the time to list the reasons for doing so, and it is quite an interesting read:

This was considered in the JDK 6 development time frame. It isn’t just monospaced, there’s also serif and sansserif which arguably should map to Cambria and Segoe UI. There are several reasons why it wasn’t done.

1. Compatibility. Applications expect the JDK logical fonts to remain completely unchanged.
2. Quality. These ClearType fonts do not render particularly well except in “ClearType” mode. Many JDK applications expect the logical fonts to be ones that render well in all modes.
3. Fidelity with native apps is the role of the Windows Look and Feel. Using Consolas isn’t remotely sufficient to make the app look like a native app. The Swing Windows Look and Feel picks up this work, and it is hooked into the fonts used by native apps, and will use the appropriate fonts.

#1 and #2 are definite concerns. For #1 and we’d need to be comfortable with the potential for breaking some apps expectations, and for #2 we’d have to at least make cleartype mode the default for these fonts, whereas the long standing default is B&W. That change could also break some apps.

So for at least for now there are no plans to implement this.

While these points sound reasonable at a first glance, they do a great disservice to Swing applications running under core look-and-feels under Vista. Let’s look at the reasons why.

As a developer of a third-party look-and-feel library, i don’t feel too attached to applications running under the native-looking skins. There have been numerous discussions over the past years on relative merits of native vs cross-platform skins, and this post is not going to rehash the same arguments. However, i would like to concentrate on a very important aspect of UI usability – matching the desktop fonts and native font rasterization.

The major operating systems on the market today use different default desktop fonts. Windows XP uses Tahoma 11, Windows Vista uses Segoe UI 12, Mac OS X uses Lucida Grande 13 and Gnome uses DejaVu 10. An application that uses the same font under these platforms will look alien on all of them, even if other visuals (such as button backgrounds) match the native controls.

Karsten Lentzsch has pioneered the font lookup mechanism in the JGoodies Looks library, and Substance has extended it to additional platforms (Gnome, KDE and Mac). If you’re running your Swing application under Looks or Substance, you get the correct desktop fonts that match the current platform settings. Why is this important? Let me show you a sample Swing application running under Windows Vista with the native Windows look-and-feel:

Only the menus use the correct Segoe UI 12 font – all the other controls are using the Tahoma 11. Karsten has opened a bug in February 2008, and it still has no comments from Sun. This brings it back to the third point in the original bug report mentioned in the beginning – Windows look-and-feel is not using the correct font. How should it look like?

This is much better, and consistent with the native applications as far as the font selection goes. If you compare it with the previous screenshot, you will notice that since the font is one point larger, the entire UI needs more space. This relates to the first point in the original bug report – not breaking the existing applications. While a noble goal in theory, this cripples the applications that do want to have the correct visuals (no matter if the look-and-feel is native or not). On a related note, this is one of the bigger visual deficiencies of NetBeans running on Vista – the smaller Tahoma font makes it less visually appealing that it could have been.

Continuing with the first point in the original bug report and the expectations of mapping logical font names to physical fonts. Once again, while a noble goal in theory, it falls apart in practice. Here is a screenshot of the same application running under Windows Vista with Nimbus:

Nimbus is using the logical sansserif font for the controls, and it doesn’t map to Segoe UI. In addition, the default font size under Nimbus is one point bigger than the default desktop font size which makes all the fonts unnecessarily larger. Here is the same application running with Segoe UI 13 (just to show that sansserif doesn’t map to Segoe UI 13 – note the difference in letters e or s, for example):

And here is how the Nimbus looks when it’s running under Segoe UI 12:

There is one more point mentioned in the original bug report – the bundled font rasterizer that wasn’t too good in rendering the Segoe UI font. While this was true for both JDK 5.0 and JDK 6.0, the upcoming 6u10 addresses this issue by using the native text rasterizer on Windows (thus obsoleting the need for the pluggable SWT-based rasterizer that was available as a separate Substance plugin).

How important is this issue to Sun? I have submitted the question on using Segoe UI 12 in Windows look-and-feel in 6u10 to the last “Ask the Experts” session, but it was not addressed at all – let’s hope that my submission was lost on its way to the server. Java2D team has made a gigantic step forward by using the native text rasterizer on Windows in 6u10. All that needs to be done is to address bug 6669448 and reopen RFE 6723343.