Anti-Aliasing Hall of Shame: Mac OS X’s menu bar
Posted by Pierre Igot in: Anti-Aliasing Hall of ShameOctober 27th, 2005 • 3:21 pm
Depending on which font smoothing setting you have selected in the “Appearance” preference pane in Mac OS X’s System Preferences, Mac OS X will actually use not just shades of grey, but actual colours (other than black) for font smoothing.
For example, here’s some text in Lucida Grande 11 pt in TextEdit, with font smoothing style set to “” in “Appearance“:
This screen shot with a 600% zoom setting shows you the individual colour pixels used by Mac OS X to create the font smoothing.
Now look at the exact same text as displayed by Mac OS X on the right hand side of the menu bar:
I have this text displayed on the right hand side of my menu bar because I use Spell Catcher, so my input menu is visible (“Show input menu in menu bar” in the “International” preference pane is checked) and I also have the option to “” on in the input menu itself (at the bottom).
As you can see, there is font smoothing as well, but it’s done entirely with shades of grey. There’s no colour involved. And the problem is not limited to the input menu. It affects all the “menu extras” on the right hand side of the menu bar that are built into Mac OS X and that involve text. For example, here’s a close-up of the text of the menu bar clock:
Again, Mac OS X only uses shades of grey. There are no colour pixels—which means that this text is not rendered using the same font smoothing style as the rest of the text in the Mac OS X interface.
It’s not like Mac OS X is not able to do proper font smoothing in the menu bar. Here’s a close-up of the “” and “” menu headings in a generic Mac OS X application:
Clearly, Mac OS X uses colour pixels here. So the problem is strictly limited to the right hand side of the menu bar.
And it’s also not like Mac OS X is unable to display colours in the right hand side of the menu bar. After all, the menu bar icon for Spotlight is in blue. The flag icons used for the input menu heading are in colour.
Yet for some reason Apple has chosen to restrict its menu extras (the AirPort menu extra, the AppleScript menu extra, the Volume menu extra, the Classic menu extra, the Eject menu extra, etc.) to black and white. And because of this restriction, it does not use the proper font smoothing style whenever you choose to use a font smoothing style other than the standard style.
I see no justification for this inconsistency, except for this arbitrary decision made by Apple to restrict menu extras to black and white. Unfortunately, it means that anti-aliased text doesn’t look the same as it does elsewhere in the Mac OS X interface.
October 27th, 2005 at Oct 27, 05 | 5:33 pm
Looks more like a bug to me that SystemUIServer somehow doesn’t know about your font smoothing preference for whatever reason.
(I’m pretty sure it’s SystemUIServer only as application menus at the right hand side of the menu bar are properly smoothed with sub-pixel rendering.)
October 27th, 2005 at Oct 27, 05 | 6:35 pm
Not sure what you mean by “application menus on the right hand side of the menu bar.” By definition, application menus are on the left hand side :). The menus on the right hand side are either Apple-supported menu extras or third-party menu bar hacks that are only “sort of” supported by Mac OS X.
Of course, the actual menu items in these menus do have the normal anti-aliasing. It’s only the menu headings that have the problem. I agree that SystemUIServer is probably involved, since it’s the background process that handles this portion of the menu bar, but at the same time it seems to me that the design decision that was made to use only black and white icons for the Apple-supported menu extras must have something to do with it as well. (The Spotlight icon is a separate case. I remember earlier builds of Tiger where the icon was quite different and it actually appeared on the screen together with the Apple menu icon on the left before the rest of the menu bar appeared, so I suspect both the Apple menu icon and the Spotlight menu icon are handled separately.)
October 29th, 2005 at Oct 29, 05 | 12:46 am
I guess it’s note SystemUIServer per se. At least the Apple’s battery plugin works as expected. If I select that it should show percentage or time on the menu bar it does it — drum roll — with proper antialiasing..
October 31st, 2005 at Oct 31, 05 | 11:09 am
I can’t check the battery indicator in Tiger because I can’t display it on my desktop. But I believe you :). Puzzling, isn’t it?
October 31st, 2005 at Oct 31, 05 | 12:39 pm
It sure is. Here’s a screenshot of my current menubar http://infa.abo.fi/~jhagman/menubar.png
I guess the reason is that inside apple there is no clear guideline and some people (programmers?) just don’t see it as big a problem as it is.
BTW Omnigraffle 3.2.4 (I haven’t upgraded to a newer one) has the same problem with not using subpixel anti-aliasing. It might be that there is some implementation detail that makes it hard to get right.
October 31st, 2005 at Oct 31, 05 | 3:10 pm
Thanks for the screen shot. Definitely uses colour pixels for the font smoothing for the battery indicator!
Well, I guess that only a developer can really tell us what’s going on here, i.e. whether it’s a problem with the API or just individual carelessness.