FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Mustang provides auto-detection of desktop antialias settings (see [1] and [2] for more details). The support for this has been added to Metal, Windows and GTK look-and-feels, and it works as expected. However, what about custom third-party look-and-feels? Well, those that extend one of the above three are OK - they get it for free. Those that extend Basic (namely Alloy, Liquid, Napkin, Skin, and Substance) are not so lucky.

This piece of code is from Metal:
boolean lafCond = SwingUtilities2.isLocalDisplay();
Object aaTextInfo = SwingUtilities2.AATextInfo.getAATextInfo(lafCond);
table.put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, aaTextInfo);

This piece of code is from Windows:
Object aaTextInfo = SwingUtilities2.AATextInfo.getAATextInfo(true);
table.put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, aaTextInfo);

This piece of code is from GTK:
gtkAAFontSettingsCond = !cjkLocale && SwingUtilities2.isLocalDisplay();
aaTextInfo =
SwingUtilities2.AATextInfo.getAATextInfo(gtkAAFontSettingsCond);

There's a catch here that prevents third-party look-and-feel from using this - the SwingUtilities2 class that is an internal one (it even has been moved into another package from Tiger to Mustang).

How can we get UIManager-level support for antialiasing in third-party look-and-feels that extend Basic?

[1] http://today.java.net/pub/a/today/2005/07/26/lcdtext.html
[2] http://weblogs.java.net/blog/chet/archive/2005/06/phils_font_fixe.html

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run application under any one of the mentioned LAFs in Mustang.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application picks up desktop AA settings.
ACTUAL -
Application doesn't pick up desktop AA settings

REPRODUCIBILITY :
This bug can be reproduced always.
Posted Date : 2006-12-19 20:19:34.0

N/A

The description in this RFE is implying that some API needs to be exposed
so that custom L&Fs can pick up desktop properties and use them as in the
standard Swing L&Fs. This is not so.
Swing uses public 1.6 API to retrieve desktop settings and the internal
implementation mentioned in the description is just that: part of
Swing's internal implementation which *use* those settings.

The way to get font smoothing settings is fully specified in
the JDK documentation :

http://java.sun.com/javase/6/docs/api/java/awt/doc-files/DesktopProperties.html

And the latest version of Netbeans (5.5) already uses this API to enable
font smoothing settings in its custom components. This is an existence proof
that the internal implementation is not necessary.

ALso note that this points out that the statement of the submitter that L&Fs which extend
Metal etc get font smoothing for free is not 100% true. If they create
a custom component which does its own text rendering it also needs to retrieve
these properties.

Perhaps Basic could provide some convenience API that does the text rendering
on behalf of a custom L&F but can that really satisfy all use cases?
And its not just rendering. Its measurement too. If a custom L&F is going
to be sized properly it needs to use the right FontRenderContext, and the
smoothing hint is part of that, even if it does not usually affect the measurement.
So I am not sure what should be done here that makes sense for Swing.
Posted Date : 2006-12-22 19:14:18.0

PS .. just as background information, it was a fairly late decision to enable
this even for Metal. The original plan was to enable it only for the native
look and feel : windows and gtk. Hopefully that puts into perspective any
notion that it was an oversight to not enable it for all L&Fs extending Basic.
Posted Date : 2007-01-02 18:52:45.0