Chet Haase's Blog

Phil's Font Fixes

The bits are in: we've just integrated LCD Text support in J2SE! You can download the latest Mustang build and check it out (we integrated this feature into build 39, which should be live now).

Phil Race was hard at work over the last several months implementing this stuff. Here's what he had to say about it:

One of the most frequently requested features has been for the JDK to support subpixel text which optimises for LCD displays using the subpixel striping to increase the text resolution. Because of the way its applied and configured by users its considered a form of text antialiasing.

On 31st May the RFE for this had reached number 6 on the BugParade RFE list with 378 votes.

The good news is this is now implemented and in mustang build 39.

The main reason for implementing this is to help the Swing native Look and Feel classes for Windows and Gnome/GTK in their emulation of the respective platform font rendering. mustang b39 now supports all the text antialiasing modes needed to support this.

At the same time as implementing this, the Windows Look and Feel and the GTK Look and Feel have also been updated to track the user's desktop preferences and update in real time as the end user changes these.

Additionally the default Java Look and Feel aka "Metal" now reads the user desktop text antialiasing preferences on start up and applies them to the JDK fonts. When used together with the Metal "Ocean" theme (which uses plain fonts instead of bold) introduced in JDK 5, the result is quite pleasing to the eye.

In a nutshell what this means is that whether you use Metal, Windows or GTK Look and Feel, you will get the same antialiasing behaviour for fonts in Java applications as in native applications. You don't have to do anything. It just works out of the box.

This is the first delivery of this work, and there's more that can be done, but it hits the big need of fixing these Swing L&Fs.

There's fairly little new API involved, although some more is expected later, for example in Swing to provide authors of custom L&Fs access to the same information as Metal.

For those interested in the details the new API in b39 is all in Java2D. There are 5 new values for java.awt.RenderingHints.KEY_TEXT_ANTIALIASING which are supported on all platforms:

• VALUE_TEXT_ANTIALIAS_LCD_HRGB
• VALUE_TEXT_ANTIALIAS_LCD_HBGR
• VALUE_TEXT_ANTIALIAS_LCD_VRGB
• VALUE_TEXT_ANTIALIAS_LCD_VBGR
• VALUE_TEXT_ANTIALIAS_GASP

The first four correspond to the 4 possible different LCD subpixel configurations. Native GTK apps support all 4 of these On Windows in native apps you need at least XP to get LCD text support, whereas JDK supports it on all OSes. Also Microsoft only supports HRGB on XP and added HBGR in XP SP1. So JDK's support here is more complete than Microsoft's.

The final oddly named hint value is used by JDK to precisely emulate what windows "standard" font smoothing does. That's what everyone with a CRT needs/uses. Its a little confusing to a lot of people as it doesn't mean all text is antialiased. It uses a table in the font (called the 'gasp' table, hence the name) provided by the font designer which stipulate the sizes at which smoothing should be done, and often that means text is not antialiased.

There are a very few other API tweaks but these are the most interesting ones.

If anyone wants to try this out, download mustang build 39 and look at the SwingSet2 demo. Also the Font2DTest demo has been updated to let you set any of the new hints and view the effects with any font or text of your choice.

(Note: All of the following pictures looked horrible in both browsers that I tried, related to automatic image scaling in those applications. The images looked fine on a different system, so they may look fine for you as well, but if they look odd, try disabling automatic image resizing or just saving the images and loading them with a local image viewing application instead.)

Or you could just look at these PNG screenshots of the JTable demo tab from the SwingSet2 demo. Without LCD text:

and with LCD text:

Here is a screenshot which shows side by side the same fonts being rendered by Windows WordPad accessory and a small JDK app which uses the same fonts and text. The fonts used here are ones typically seen in windows apps.

Similarly, here's a snapshot comparing some of the more common fonts seen in Gnome apps on Linux side by side with the JDK rendering of these fonts. The Gnome text was rendered on Fedora Core3 in the "gedit" application. Since gedit can only use one font at a time, the text was snapshotted and stitched together using gimp for ease of comparison.

Note : these images are prepared for viewing on a "HRGB" LCD display. That's by far the most common. If you are using a CRT don't expect to see much improvement. Also if your LCD display isn't connected by a DVI connector you'll not get the best experience either. A VGA connector just doesn't have the precise addressibility needed to get good results from this.

So that's all the important news about it: check it out, download it, play with it, tell us what you think.

Now, the less important but more interesting part, at least to this graphics geek: how does it work? There's information out there on the web so you can chase this down if you want more details, but the basics of LCD text involve details of how the eye perceives color, and how we can use that physical reality, along with the physical construction of LCD monitors, to display a higher-quality anti-aliasing effect. I originally hoped to cover this geeky topic here, but when I crossed the 400th line of text, I realized that it was more of an article than a blog entry. I'm working on that article now and hope to publish it sometime next week; stay tuned...

In the meantime, download the release and play with it; we think you'll like it.

Comments

• This is excellent news and a big thank you for it!

  I took a look at the screen shots and they all look
  great. Java2D's version looks better than Fedora's
  version too. However, I noticed something about
  the version comparing with MS's WordPad. The
  'M' in the word Microsoft in the 2nd paragraph is
  not satisfactory. The 'V' in the 'M' clearly is not
  perceived to be same width as the vertical strokes.
  Is there anything that can done about this?

  .rex

  Posted by: rexguo on June 06, 2005 at 10:04 PM

• There is also a glitch in the lower case "y" of "lazy dog". You can also spot problems when using Courier New with a font size of 11. This is a bug in the font rasterizer and I'm sure it'll be taken care of very soon.

  Posted by: gfx on June 07, 2005 at 12:48 AM

• rexguo and gfx: There are some individual glyph issues above. These are not related to the LCD Text work, but are rather (as gfx points out) bugs in the rasterizer that will be fixed separately.

  Posted by: chet on June 07, 2005 at 06:34 AM

• It's not clear to me why subpixel addressing is necessarily related to text rendering. My particular concern is that if my application uses transformed GlyphVector outlines, how does the rendering engine "know" that the Shape I am passing to Graphics2D.draw is text and should therefore use subpixel rendering? My guess is that it will not, which effectively will force me to use a higher-level API like TextLayout or drawString.

  Posted by: herbyderby on June 07, 2005 at 02:29 PM

• herbyderby: Right - we have no way to know that the Shape you are passing in has anything to do with text, so no text flags (LCD or otherwise) will be applied to it. You will have to use the text APIs to get any text related rendering enhancements.

  Posted by: chet on June 07, 2005 at 04:05 PM

• I wasn't sure this was going to turn out well, because I know I can surely tell the difference between Windows, Gnome, and OSX subpixel antialiasing. I assumed Java would end up looking bad until the exact rendering algorithm was duplicated for each platform.

  However, it looks great here on Windows. I think this is exciting.

  I have a question: why is only text antialiased in this way, and not all drawing operations?

  Posted by: keithkml on June 07, 2005 at 08:14 PM

• keithkml: I think the reason to do this on text and not elsewhere is that we are far pickier about text AA than we are on other drawing primitives. If a diagonal line looks "smooth" using some simple AA algorithm, I think that's probably good enough for most people. But if a small glyph uses that same simple AA algorithm, it can come across as blurry or distorted, and just basically crummy. So if we're going to focus efforts on improving quality in this particular area, let's fix the outstanding problem: font quality. Given the time and resources, applying this algorithm general rendering primitives seems interesting, but I think there are probably other quality and performance issues that are higher priority.
  

  Posted by: chet on June 08, 2005 at 11:53 AM

• Looks great, but I noticed in the side-by-side screen shot that the JDK renders the fonts significantly different from Windows. Look at the W in BROWN for Microsoft Sans Serif for example. Or notice the different widths for hte U/u in the Arial font.

  What's the reason for that? Should we not expect the font to render exactly the same?

  Posted by: swpalmer on June 08, 2005 at 10:23 PM

• Argh.. Why didn't it show any other comments until AFTER I posted mine?

  Posted by: swpalmer on June 08, 2005 at 10:25 PM

• How can you switch on subpixel anti-aliasing for Swing components when your O/S doesn't have this? You stated above that for example, only Windows XP has this, but older versions (such as Windows 2000, which I'm currently using) don't, and "the really great thing" is that by using Java, it can be made available everywhere.

  Having looked through some of source code for Java 6, I got as far as com.sun.java.swing.plaf.windows.WindowsLookAndFeel and com.sun.java.swing.SwingUtilities2, and could see the some sort of desktop property setting behaviour was going on, along with UIDefaults properties, but got totally lost in the maze of code, and couldn't figure out which properties to use. In any case, it appears that I'd have to use some Sun-specific stuff and so it wouldn't be cross-implementation if I started touching that...

  Any "Hello World" JFrame examples that uses subpixel anti-aliasing on ANY O/S, irrespective of desktop settings? I don't want to use Graphics2D and RenderingHints everywhere, instead of using JLabel, JButton, and company!!!

  It's great that it's been implemented... It'd be nice to let us know how to use it in the way you described...

  Thanks,
  - Chris

  Posted by: chris_e_brown on July 25, 2005 at 06:43 AM

• How can you switch on subpixel anti-aliasing for Swing components when your O/S doesn't have this

  Since Windows 2000 doesn't natively support LCD text, on W2K Swing will not
  see a Windows desktop setting that specifies it. So if you want it in a Java
  application you are going to do *something* to make it happen since I
  hope it should be obvious that it would be wholly inappropriate that Swing
  always do LCD text on all Windows 2000 systems regardless ..

  The proposal is that you (the developer or the sysadmin) set a Java
  system property which overrides any actual desktop settings such that
  Swing sees instead what you specified :

  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6291810

  This can be used on any OS/desktop that JDK doesn't recognise
  desktop settings.
  

  Posted by: philrace on July 25, 2005 at 10:02 AM

• I reposted here:
  http://forums.java.net/jive/thread.jspa?messageID=19868&tstart=0#19868

  ...after resolving a network problem where I was. I know Windows 2000 doesn't have a desktop setting for this. However, when painting text with Graphics2D, it's possible to enable this programmatically; I'd think it logical to be able to enable it on any look and feel for Swing without being forced to write your own look and feel.

  While "if the native look and feel doesn't have it, then the Swing clone shouldn't either" is debateable, it should be possible to enable it for Metal/Ocean for example, which already deviates from "native" look and feel anyway. In such scenarios, why deprive users with LCDs from the enhanced readability it provides?

  Posted by: chris_e_brown on July 25, 2005 at 03:01 PM

• An RFE related to my previous postings is now in the bug database (it's not showing up yet though):
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6302464

  Posted by: chris_e_brown on July 27, 2005 at 05:03 AM

• So will a (truly) public API be provided for getting the default Look&Feel values of text antialiasing and contrast - the stuff that is used internally in SwingUtilities2 now - so the text antialiasing in custom components can be made to match Swing components? 6274830 doesn't really address this, since "a rendering hint be provided which requests that LCD mode be automatically
  optimized for that device" isn't the same thing as matching the values used by Swing components in the current Look&Feel.
  

  Posted by: lbarowski on August 04, 2005 at 01:52 AM

• Who answer me ? What with #bug4479178 - RFE: Support for Transparent windows required and Non-Rectangular Windows. Is a chance to realize it in Mustang ? It is very important ref. in my opinion.

  Posted by: majo44 on August 31, 2005 at 02:18 AM

• hi - I was wondering, setting system property "swing.aatext=true" switched on antialias textmode in swing components under linux for 1.5, but in 1.6 beta I am seeing ugly non-antialiased fonts in all my swing components.

  Is there another system property I need to set in order to enable it for swing?

  Posted by: ezust on February 26, 2006 at 02:11 PM

• from the soon to be posted updated 2D FAQ :

  Q. How can I specify the text antialiasing/font smoothing settings to be used by Swing in applications on Java SE 6?

  A. This is generally is a question from users of KDE or Windows 2000 who would like to use LCD subpixel text. There's no programmatic way to do it in Java SE 6 (However if you know what you want you can set a system property :

  java -Dawt.useSystemAAFontSettings=lcd
  which request to use LCD subpixel text in the most common subpixel configuration There are a few more useful values for this property as follows :

  "false" corresponds to disabling font smoothing on the desktop.
  ""on" corresponds to Gnome Best shapes/Best contrast (no equivalent Windows desktop setting)
  ""gasp" corresponds to Windows "Standard" font smoothing (no equivalent Gnome desktop setting)
  ""lcd" corresponds to Gnome's "subpixel smoothing" and Windows "ClearType"
  

  Posted by: philrace on February 26, 2006 at 05:35 PM

• PS also see :
  http://java.sun.com/javase/6/docs/guide/2d/flags.html#aaFonts

  Posted by: philrace on February 26, 2006 at 05:40 PM

This work is licensed under a Creative Commons License.