Matching desktop fonts and native font rasterization
July 29th, 2008 | 16 Comments »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.
- Compatibility. Applications expect the JDK logical fonts to remain completely unchanged.
- 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.
- 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.
Related posts:
- Native text rendering in Swing applications – ready, steady, go! The subject of native text rendering in Swing applications has been introduced on this blog...
- Control alignment under different fonts in Substance 6.0 After taking a deep dive into the intricacies of aligning text components, comboboxes, spinners and...
- The perils of implementing a Swing native look-and-feel This forum posting on the SwingX forum has caught my eye: Having recently switched my...
- Native text rendering in Swing applications Yesterday i posted six screenshots divided in two groups and asked what is the difference....
Thanks for stopping by. My name is Kirill Grouchnikov and I am a user interface engineer. I have been doing client side development professionally over the last decade or so, in a variety of UI toolkits and libraries that spanned Motif, MFC, VB, Ada, Delphi, Swing and SWT. Recently I joined the
Hi Kirill: I think the more pertinent question at this point is: what is, and what should be, the role of the Sun Swing team as regards these issues. I think their role should be to solidify the foundation of the UI toolkit they support, and that as far as L&Fs that aim to match a native L&F, they should declare victory, and retreat. The work done on the native L&F within Swing shows that it is an achievable goal, but that fixing the last 10% of the problems will take a great deal of effort, and likely “break” existing apps. For my part, I think their focus should be on the “non-native” L&F, such as Nimbus, plus making sure that third-party L&F developers have what is needed in the toolkit to get their job done. These highly specific issues, such as which font to use on different OSs to match the native selection, just seem like a waste of Sun resources that could be better spent elsewhere. I’d rather use (or even buy) a third-party L&F for Windows that did the job (nearly) perfectly than ask Sun to keep chasing these problems down.
I realize that Sun took this burden on in the first place, but I’d rather see both Sun and the developer community just agree to leave it to third-party developers at this point. In fact, a solution might be to separate out the implementations for the Windows, Gnome, etc. UI delegates to a separate OS project that could be maintained and fixed apart from the JDK release cycle.
IMO,
Patrick
I 100% agree with Patrick. Frankly, I think every effort spent on native L&Fs is a complete waste of time. It will never be perfect and the only people who really, really, really care are Mac people. If we could just produce one modern-looking, cross-platform, not-too-flashy L&F this would make 90% of people happy. In this specific case where Nimbus doesn’t match the native font I’m not sure it’s such a big deal. Fonts are the sort of thing people can get picky about (they’re always either too big or too small) but, again, it’s by no means a deal-killer or critical issue.
“I’d rather use (or even buy) a third-party L&F for Windows that did the job (nearly) perfectly than ask Sun to keep chasing these problems down.”
While the above seems reasonable, I have to agree with Kirill. The point is that while Patrick’s attitude to even buy a third party’s software for making his applications better is good, most developers won’t care of it. In the end, the usual attitude in the Java community of desktop programmers is to not care enough about this subtle points; the net result is that most of the Java desktop applications around will lack that remaining 10%. There is a proof of this assertion: while people could have written pretty good Swing applications in the latest two years, most of Swing applications have still rough corners. It’s not an easy point to fix, since it’s related to the habits of our community – unfortunately, there is a sort of “digital divide” between most Java desktop developers and the culture of competitors’ communities such as Adobe’s. The consequence of this is that most Swing applicaitons will be poo-pooed by the Adobe’s community, where people are much more focused on this kind of stuff. Which will turn to be another point for Flex and Air, as we didn’t have a hard job for defending Swing as things are now.
For this reason I agree with Kirill, that Java should deliver accurate native rendering out-of-the-box. There is definitely space for third parties’ look and feel providers, but they should be for people that want customized look and feels, not native ones.
Fabrizio: I simply don’t believe Sun has the resources to deliver accurate, native-style L&F for multiple platforms–several versions of Windows and Gnome at the least–while still fixing bugs in Swing and working on extending Swing. It’s simply an enormous effort. It’s not that I don’t agree the goal isn’t a good goal, but rather that it seems pointless, after all these years, to continue berating Sun about these issues.
I would rather that Sun focus most of their L&F effort on Nimbus, plus fixing any Ocean/Metal issues, with the goal of at least having those toolkits look and work really good out of the box.
I would rather have us, as a community, move away from these sorts of discussions. For my part, “leading” Swing apps such as IDEA are great because they offer a really well-integrated, comfortable experience for me as a user; I feel productive using it. I don’t really care if there are minor L&F issues. I can’t imagine that anyone else would, either. I do think they care if menu or button accelerators don’t work, if there are focus issues, etc. Those are the cross-platform issues that bug me. And I’d rather see Sun investing time on those issues (and on new features, such as prototyped in SwingX).
Patrick
The RFE seems to be talking about changing logical font mappings, not directly about the Windows L&F and what font it uses.
What if the Windows L&F picked the appropriate physical font (e.g. ‘Consolas’ instead of the logical font ‘Monospaced’) depending on the OS and the logical font mappings were left alone? Does this already happen? (what if user changes default font through display properties?)
The question is: as a developer do I want Consolas picked when I use the Monospaced font everywhere in my application? Or should this font be read from some kind of desktop property?
The look is either right or it’s wrong. Period. No latitude.
Mac users are very picky about the UI. I write a lot of crossplatform desktop apps. On the Mac I have to go to great pains to make sure my Java code looks and feels like a Cocoa app. That’s what my customers expect. Some Windows users care a lot too.
If Sun’s goal is to have a first class desktop presence, they have to pay attention to what users want. Do users want a crossplatform L&F? No, not on the desktop! Some developers won’t use Java because it takes a lot of work to create a first class native-looking app.
Sun needs to have a one-line call that sets everything to native L&F. I can understand their resistance to changing the default, but they need a property that sets the UI into a Sun-tested native mode. This will promote Java’s use on the desktop, and stop users from saying “ewww, it’s a JAVA app…yuk!”
For folks who say Nimbus is good, you’re missing the point. If the look isn’t right, then it’s wrong. Nimbus isn’t native, therefore Nimbus isn’t right, therefore Nimbus is wrong. If this sounds dictatorial and Steve Jobs-ian, it is. Nowadays, users care about and demand specific details in the UI for their desktop apps.
(BTW: I do like Nimbus for use with JavaFX. Web apps have different L&F requirements than desktop apps, and when you compare against Flex, Nimbus is both appropriate and needed for software on the web.)
Sun really need to do something.
GUI apps should be Pixel Perfect.
if my Swing app does not look like my other native apps, sooner or later I will go to SWT. Simple.
Pixel-perfect L&F should be the goal of Swing.
If QT can do it…
The smart thing for Sun to do would be to add a Compatibility API. That way you could specify that “I am developing this with xxx version in mind and would like to have the defaults as perfect as possible, without regarding backwards compatibility to versions before this”
“For my part, “leading” Swing apps such as IDEA are great because they offer a really well-integrated, comfortable experience for me as a user; I feel productive using it. I don’t really care if there are minor L&F issues. I can’t imagine that anyone else would, either.”
Patrick, this is the view point of a software engineer. The biggest problem of the Java desktop community is that it is made of software guys and keep on reasoning as software guys. If you want to gain positions on the desktop, end-user segment, we must start thinking as graphic designers. As a software engineer, I think that IDEs such as IDEA, NetBeans, Eclipse, are rocking products. But if you deliver a desktop application with their look and feel and addressed to end users, most of them will just poo-poo them. Adobe has clearly in mind this fact, because their community is made by graphic designers, and I’m really worried about that – even with a product such Air/Flex that technologicically IMHO is vastly inferior to Java, they can win the battle for a matter of pixels.
Furthermore, as John said, there’s the Mac OS X thing where this sort of things are pushed to extreme points. I understand that Mac OS X is critical mostly because Apple’s attitude with Java, but it seems to me that we tend to ignore it too much. If we’re talking about the desktop, Mac OS X can’t be ignored even though it’s a small segment.
Hey Kirill,
Talking about bugs and Sun’s handling… Were you aware of this one?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6497929
Basically any modal-dialog-on-modal-dialog in 1.6 causes a big memory leak. This also goes for a JOptionPane shown on top of a modal-dialog.
Do users want a crossplatform L&F? No, not on the desktop!
Sorry, but no. I’ve seen several (unfortunately internal) usability studies again and again that make it very clear that native L&F is simply not important to the vast majority of users — especially in the corporate workplace. And if you take a look at what applications are actually popular these days: web apps, flash apps, widgets — surprise surprise, absolutely none of them use native L&Fs. What users care about is flashiness and performance. If a font is 1-pt too large? Not so much. This boat has sailed. Again, it’s a total waste of resources for Sun to try and do pixel-perfect native rendering. It’ll never happen, it’s overly ambitious and users simply don’t care that much. Native L&F might have been a reasonable strategy ten years ago where the goal was simply to get the foot in the door but it’s no longer necessary to continue this submarine strategy when Java’s popularity is well established and there’s a deep ecosystem. I’ve seen this again and again: developers *want* to use Java to build an application but the end result isn’t flashy/slick/”wow” enough and so Flash or desktop rendered html is chosen. This is unfortunate because people would like to leverage their Java experience but right now it’s just too difficult to build something “wow” with Swing. Sun really ought to focus on this — and JavaFX is a step in the right direction though I really wonder why we needed a whole new language, argh — and forget about trying to emulate legacy UIs.
I’m leery about studies that contradict my day-to-day experiences. Perhaps corporate America doesn’t care about the user experience, but my customers do.
The desktop and the web are two different worlds. Desktop apps, at least on the Mac platform, have a distinctive look. Mac users highly sensitive to L&F, and buy accordingly. It’s financial suicide to give my competitors the advantage of having a product that looks and feels like a Cocoa app, and for me to try to sell them something that is clearly foreign.
For Java to gain ground on the desktop, Swing needs to provide better native L&F. If that weren’t the case, then why aren’t Java apps dominating the desktop world?
The web world is another story. As noted in my original post, I think Nimbus will be important for RIA. It’s a slick GUI, and is competing in a more wide-open world. Even Mac users seem ambivalent about UI in the browser.
So why do I develop in Java? First, I can make Swing indistinguishable from Cocoa on the Mac platform. It take a lot of effort (there is SO much that is subtly “wrong”) and I have to do a lot of JNI, but I can do it. Secondly, I’m a big fan of what Sun’s doing with JavaFX. I expect to be able to leverage a lot of my existing code when using it. Being able to develop first-class crossplatform desktop apps and leverage that in RIAs is IMO a killer reason to use Java.
Sun is THIS CLOSE to providing a good desktop experience and a good RIA experience. But to convince desktop developers to use Swing, Sun can’t take away the native L&F developers can so easily achieve if they use Cocoa or .Net.
Has anyone attempted to put together a poll
and stats on what people think about these
issues? If there is an exhaustive study and
well-represented data, then it ain’t too
difficult to get Sun to go a certain direction
since majority wins here. It’d also be much
more efficient for Sun to not have to look
at a broadly distributed pool of comments
and opinions from blogs, forums, newsgroups
and newsletters.
Heh… I am actually the author of the aforementioned RFE.
One thing that really bugs me about Sun is that any GUI-related issues are automatically flagged low priority and the point they keep on missing is that if Java 6 Update 10 is supposed to be about “Java on the Desktop” then these issues need to be *high* priority instead!
Secondly, I would point out that regardless of whether you prefer cross-platform or native rendering, applications that *want* native rendering should be able to get it. When an application explicitly selects the Windows L&F, I argue that the logical mapping should map Monospace to Consolas, period.
Krill, is there a way for you to reopen this discussion with Sun (with respect to the RFE) in a java.net forum or by filing a new RFE?
Gili,
Thanks for your interest. I have stated my thoughts on the subject in this blog entry, and if Sun’s Swing team is interested in a further open discussion on java.net forums, i will be joining such a discussion.
Kirill