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

or

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


This is reproducible on 98,ME,2000 & XP.

* From right click on desktop click "Properties"

* From the plus tab select font smoothing (or clear type from XP's
Appearance/Effects/Font Smoothing ... where it's more obvious)

* Apply the settings.

* Inspecting any TTF/OTF font from any (non-java) program in detail should
reveal anti-aliasing behavior (this will not apply to rasterized fonts such as
System or Lucidia or Courier ). A typical example may be courier new italic
under notepad at a large size. Notice the smoothness of an l or I when it is
italic.


* Go to %JAVA_HOME% (pick your favorite jdk) and run the stylepad demo
in /demo/jfc/Stylepad with ../../../bin/java -jar Stylepad.jar

* Compare the results to what you saw with notepad. Pick any equivalent font.
Set the size equally high. It will be jagged. There will be no way (other then
to set the Rendering hint programmatically to force anti-aliased output) to
produce anti-aliased results.

It would be nice if this setting followed the OS default.

The antialias setting is a combination of the font-quality flag passed in at
the time the font is created (it should be highest-quality not 0 ) and the
surface the text is drawn on (printers for example are not antialiased).

I have tried to modify this default by search/replacing the font quality on
all create fonts that I could find in awt.dll and jawt.dll without success
which leads me to believe the problem is related to the property of the
drawing surface or a font created in Graphics2D. I would bet that a flag on
the creation of the drawing surface would fix the problem.
(Review ID: 131598) 
======================================================================

Set the anti-aliasing render hint on the object before drawing to it however
this is distinctly different then using the windows os to do font aliasing b/c
the font metrics are forced to be the same aliased or not (unlike java which
antialiasing will change the font metrics ). Also windows forces the font
smoothing on programs rather then programs having to specifically have built-
in support for it. Thus it's relatively low-impact to make the change to the
jdk (even a properties setting would be cool ).
======================================================================

This is an interesting idea that deserves further investigation.
  xxxxx@xxxxx   2001-11-14

This has been implemented for Gnome (5030990), so that this bug is now just
against Windows.  A bug was recently filed against this (5057309), here is
the evaluation from that bug:

From Phil:
> If you look closely at a windows desktop you'll
> see that asking windows to do A-A does *NOT* A-A all or even most text.
> We have no way to express that and in fact at almost all typical
> GUI sizes fonts say "please do NOT AA me". This is in the
> table of a TrueType/OpenType font and almost all fonts say not
> to do so for 7->14 pts which is the size range you'll see in most GUIs.
> So by turning it on on windows in a blanket fashion we'd actually
>be more divergent than we are now!
>                                                                                
> Addressing this needs a new hint or other mechanism and additional
> supporting code etc.

Additionally our use of composite fonts makes this a bit tricky:

> We'd probably have to pick the behaviour of just one
> of those fonts, probably slot 0. To do otherwise a
> single string would be drawn with AA and non AA glyphs
> which would not only look weird but be a nightmare for
> our blitting loops.

The customer also added:

> I took a screenshot of my Windows XP desktop with zoomed-in parts of
> various text. I posted it at http://kano.net/in/desktop. When you look
> at the image you will see that there is no text on my desktop nor on any
> of the open program windows, which is not anti-aliased. I did not enable
> anything special to do this.

And Phil comments:

> I looked at the snapshot and it was immediately obvious
> that's because he's enabled ClearType anti-aliasing, not
> standard anti-aliasing.
>                                                                                
> ClearType works differently and always
> anti-aliases. If he switches back to "standard" he will see
> the behaviour I described. Its accessed in the same place
> as the standard smoothing user option, its just a different option.
>                                                                                
> We have an existing RFE (which you are welcome to look up
> as I don't have the bug ID handy) to implement something similar
> to cleartype.
                                                                                
So, there are two issues here:
1. We need a way to get whether or not we should turn on AA for the font we're using,
   this will come from 2d.
2. We need to support clear type.

The 2nd issue is already filed as 4871297 which is waiting on the 2d
bug 4726365, so this bug is now just against 1.
  xxxxx@xxxxx   2004-06-04

The 2D bug for 1 is 5057760.
  xxxxx@xxxxx   2004-06-04

4726365 and 5057760 have been implemented, as well as 4871297 which enables
the AA settings for the platform look and feels.

This bug is being marked fixed to reflect that Swing's Java Look and Feel
(Metal) also now picks up on start up (or L&F installation), the same desktop
font AA settings and applies them. This doesn't change the font that Metal
uses, but it picks up the AA technique that the host OS desktop would use
for the Metal font and is applied automatically applied (ie by default as requested).


  xxxxx@xxxxx   2005-05-19 18:21:16 GMT

Fix this!

It's a pity this problem has not been solved after 2 years! 
Font antialiasing has become very important now as many 
people switch to LCD monitors.

Please get this fixed.  Chinese fonts on Linux is very ugly
because of this problem.

Class in rt.jar:
sun.java2d.SunGraphics2D

Hard coded Variable
textAntialiasHint = 0

if could be loaded from a properties ;-)

Swing apps stand out like a sore thumb on Windows XP with
ClearType turned on. SWT, or even an AWT, applications look
much better, as they use the native OS text rendering in
most cases.

Is this going to be fixed by 1.5 Release?

I heard this will be fixed in 1.5.1.

For heaven's sake fix this! Java looks butt ugly without this. As usual Java UI is at least 3 years behind Windows state of the art. How long did it take you guys to implement the mouse wheel. LOL! Sun has lousy Java UI developers.

A workaround is to set the system property swing.aatex
to true.

Sorry the system property was incomplete.:

swing.aatext


This boolean property dis-/enables anti-aliased text rendering.

Why isn't there a system property or something in Graphics2D that allows defining the default settings of new Graphics object instances before it is sent and used in Swing components "paint" methods?

(Note that Swing uses a shared Graphics2D object that is reused across component paint methods. It is initially set with some settings according to the default look and feel and other system properties and then each component modifies a few of its properties when needed to draw themselves, and Swing Component paint methods should save and restore the previous state of this Graphics/Graphics2D object).

So why can't we define somewhere a default rendering hint, so that Swing components would immediately inherit of this setting without forcing application developers to subclass all the Swing components to set and restore the desired rendering hints?)

Do we have to create a separate hierarchy of Swing-based components, that just change their "paint...()" methods by setting the rendering hint in the Graphics2D parameter before using the supermethod to perform the actual draw, and then restore the Graphics object?

Shouldn't the rendering hints come from Look and Feel and local native platform settings?

Implementing ClearType now is not the first priority. 

First implement a way to properly set the default rendering hints used in Graphics2D objects instanciated by the Swing JComponent classes.

If this is done, then you can add a ClearType/subpixel antialiasing mode in AWT and Graphics2D... if possible due to platform licencing issues on this technology:
if not available, the Sub-Pixel Antialiasing mode should behave at least like standard Full-Pixel AntiAliasing mode.
To make sure that the SubPixel Antialising mode is properly set, may be it should be a separate rendering hint (ANTIALIASING_MODE_KEY) with various values (ANTIALIASING_MODE_VALUE_DEFAULT, ANTIALIASING_MODE_VALUE_FULLPIXEL, ANTIALIASING_MODE_VALUE_SUBPIXEL, ...) which will take effect only when the existing boolean-like Antialiasing hint is enabled.