Font Rendering in NetBeans IDE
The quality of text rendering in any editor is of great importance. Text set in the same font and size can look noticeably different not only due to different monitor hardware, but also due to different software renderers used in different editors or operating systems. NetBeans (similarly to other IDEs) supports sub-pixel rendering which is the state of the art technology to improve font appearance on LCD screens. The effect of sub-pixel rendering is most beneficial on screens with low to mid resolution, as is the case of mainstream laptops and monitors.
In older NetBeans versions there was an antialiasing option in the Options window (Tools | Options | Editing | Editor Settings | Text Antialiasing). This is no longer surfaced in the Options panel for reasons explained below.
Remark: Manual setting is still possible. In file netbeans.conf in etc/ sub-directory of the NetBeans installation directory add to property netbeans_default_options two more arguments: -J-Dswing.aatext=true -J-Dawt.useSystemAAFontSettings=lcd. See the following for details about useSystemAAFontSettings.
Anti-aliasing in NetBeans 7.1
NetBeans uses the Swing text renderer. Since JDK 1.6 this renderer supports sub-pixel rendering in addition to standard anti-aliasing. The renderer supports several operating modes. According to
if the antialiasing switch awt.useSystemAAFontSettings is not set, then Swing text renderer tries to detect the optimum setting for given system and use that. Since 1.6 the renderer implements the following options:
- off | false | default - meaning "do not override what has been auto-detected"
- on - use anti-aliasing without sub-pixel rendering
- gasp - use anti-aliasing wit sub-pixel rendering, intended for use both on CRT and LCD
- lcd - use anti-aliasing wit sub-pixel rendering, optimized for LCD
- lcd_hbgr - same as lcd, but with different distribution of sub pixels (monitor upside down)
- lcd_vrgb - same as lcd, but with different distribution of sub pixels (monitor is vertical)
- lcd_vbgr - same as lcd, but with different distribution of sub pixels (vertical again but on other side)
See the attached screenshots for how text looks in NetBeans for various awt.useSystemAAFontSettings values on my Win7 system with LCD screen and JDK6_u29.
|default, i.e., no awt.useSystemAAFontSettings set looks arguably the best (although with all the reservations pointed out by users) - clearly showing that Swing indeed does take the actual value from the system. In this case sub-pixel rendering is used in all fonts in menus, tabs, editor.|
|lcd is equivalent to the default with one difference - for some reason this option is not used for AA in tab headers; with them it uses only the inferior rendering of option on. But editor font rendering is apparently the same as in default|
|on uses AA for text in menus, tab headers and editor, in all cases the quality of AA is inferior to lcd as the renderer is more general and thus less optimized for the current (LCD) system|
|gasp seems to be inconsistent; menu text is rendered in the same way as in the on option, text in tab headers and in editor is NOT anti-aliased|
|off seems inconsistent as well; text in menus is not anti-aliased as expected, but text in tab headers and editor is anti-aliased according to the on option|
With lcd_hbgr, lcd_vrgb, lcd_vbgr the result looks much worse due to excessive blurring and unwanted greenish halo around letters.
The switch swing.aatext=true does not seem to make any difference except that with it small fonts get occassionally rendered worse than without it.
The difference between Eclipse and NetBeans font appearance follows from the fact that Eclipse uses swt which uses native font rendering while Swing does not. Any substantial change in NetBeans rendering would require to bypass Swing renderer in favor of native renderer, what is currently not supported by Swing.
It can be noted that Microsoft's ClearType sub-pixel rendering technology seems to have reached a more mature state than the less OS specific Swing technology. This is not surprising given Microsoft has been investing a lot in typography, fonts and their rendering in Windows since Vista while Swing evolution apparently slowed down.
The default NetBeans editor font Monospaced can be replaced by any other fixed-size font. However, Monospaced proved better legible than many of the common fixed-width alternatives including Consolas, Lucida Typewriter, Courier New.
In bugzilla we have
where users advocate to have the AA switch surfaced in Options. Given the observations above it can be seen that the AA switches would not make any good difference if made available to users through surfacing in Options. Swing seems reasonably reliable in detecting the best system settings, manual changes are thus unlikely to bring any improvement.