Is it just me, or is there a distinct lack of polish in this picture that is really quite unexpected in an Apple product these days? The problem is particularly noticeable in the top halves of the round parts of the music notes and along the top edge.

Here’s a 400% close-up of that edge:

There is clearly some amount of anti-aliasing here, but it is also quite clearly not sufficient to hide the very ugly “staircase” effect, which is precisely what anti-aliasing is supposed to be good for.

And this “staircase” effect is very much visible, at least in my eyes, even without the 400% zoom. It’s even worse for the smaller version of the graphic in the “Preview” column in a Finder window in column view:

Everything else in Mac OS X is so smooth and so sleek that this flaw really stands out. And I work with lots of music files on a daily basis, so I see this all the time.

I find it really quite puzzling that Apple’s engineers find this perfectly acceptable, while everywhere else in Mac OS X they do their best to use anti-aliasing to smooth any rough edges.

Am I really the only who’s bothered by this?

The problem is that, apart from the iPhone (which John Gruber says has 160 dpi), most LCD screens used by Apple users today do not have such a high resolution.

My worry is therefore that, because of some future hardware improvements that will eventually make sub-pixel anti-aliasing irrelevant, Apple is simply not bothering to implement sub-pixel anti-aliasing consistently across all its applications today.

The problem is particularly crucial in an application such as Pages. It is, after all, a word processor (and page layout) application, which means that it is an application where people are staring at text all day long.

Is it really acceptable that sub-pixel anti-aliasing is not supported in Pages today because, say, five years from now, many Mac users will be able to use LCD screens whose resolution is high enough to make sub-pixel anti-aliasing irrelevant? Do we really have to live (and work) with this flaw on a daily basis for years while waiting for our hardware to catch up?

Unfortunately, Apple’s track record with the software/hardware disconnect in recent years suggests that the answer is “yes.” I still remember trying to use early versions of Mac OS X on a G4 and observing the scandalously high amount of CPU power that was purely and simply wasted on useless eye-candy, to the point that the whole work environment was slower than it could and should have been. Did Apple ever eliminate or streamline the eye-candy? Of course not. They just forced us to live with it for years, with the huge amount of time wasted associated with it, until the hardware was fast enough to make the waste of CPU power largely irrelevant.

I suspect that they are going to do the same here. Which means that, yes, we are going to have to live (and work) without sub-pixel anti-aliasing in iWork applications until our LCD screens have a resolution that is good enough to make it irrelevant. That is years of having to stare at subpar text rendering.

Sigh.

But that’s no excuse not to use Mac OS X’s standard font smoothing scheme when rendering text in user interface items. Yet in that respect, Adobe Illustrator CS2, which came out in 2005, feels like an application from 10 years ago.

This, for example, is the “Character” palette:

Look at the text in the various fields. It doesn’t even use any font smoothing at all!

There’s absolutely no excuse for this, especially since other Adobe CS2 applications are not affected by the same flaw. Here’s the Character Palette in Adobe InDesign CS2:

If they can do it properly in InDesign, why can’t they do it in Illustrator?

The only possible conclusion is that, in typical Microsoftian fashion, they don’t care.

And then of course, we get the usual white smears in various places. Here’s an example in the “Preferences” dialog box:

Yuck.

Here again, InDesign has tons of text fields in its own “Preferences” dialog box, and none of them suffer from the same visual flaws when the text is selected.

It’s just pure user interface sloppiness and carelessness. And it comes from one of the major providers of professional-level Macintosh software. It’s absolutely shameful.

Standard font smoothing does not use subpixel anti-aliasing (it only uses shades of grey, not coloured pixels) and, for most people, this type of font smoothing looks “skinny” and excessively blurry on a flat-panel display. Hence the other font smoothing options provided by Apple in System Preferences, including the “Medium – best for Flat Panel” option.

Both versions of Pages (1 and 2) fail to honour the user’s preference as selected in the “Appearance” preference pane. Regardless of the user’s preferences, Pages uses standard anti-aliasing with pixels only in shades of grey.

Other people have recently chimed in on the issue.

John Gruber says that I think it’s due to Apple’s “incompetence,” even though I never used that word myself in my posts on the subject. I did say that it was quite “unbelievable” that the problem was still not fixed, and I did speculate on the reasons for this. But like I said in a comment on Michael Tsai’s blog item on this topic, Apple’s apparent “refusal to fix [the problem] leaves the door open to speculation about its reasons/motives.”

In any case, people who know more about the technology used for font smoothing than I do have provided more clues about the root of the problem. In particular, Michel Fortin states that it is “simply impossible to draw subpixel anti-aliasing on a transparent background” (his emphasis).

Since Pages is also a page layout tool and has to support transparency, it appears that this is the reason for Pages’s lack of support for other font smoothing styles. In other words, it appears that Apple engineers have decided that the lack of support for subpixel anti-aliasing in Pages is an acceptable trade-off.

The trouble with this is that it is not entirely convincing. First of all, Apple has made no attempt to communicate with Pages users on this subject and justify its decision. The lack of support for other font smoothing styles is not mentioned anywhere in the Pages documentation or on Apple’s web site, as far as I know. And the bug reports I have submitted on this issue have remained unanswered too.

This is not a small issue that will just go away by itself. Font smoothing is an essential dimension of the visual experience in Mac OS X, and the lack of support for subpixel anti-aliasing in Pages causes a significant amount of undesirable eye strain for Mac users with flat-panel displays. Given that Pages is not just a page layout application, but also a word processor, this is a rather fundamental issue.

Then there is the troubling fact that this is not an isolated incident, and that Apple also fails to honour the user’s font smoothing style preferences in other parts of Mac OS X, most notably in the right-hand side of the menu bar. What’s the excuse for not supporting subpixel anti-aliasing in menu extras, when subpixel anti-aliasing is fully supported in menu items on the left-hand side of the menu bar?

Finally, there is the fact that Pages’s main competitor and runaway leader of the word processor market, Microsoft Word, does support subpixel anti-aliasing and does honour the user’s font smoothing style preference as defined in the “Appearance” preference pane in System Preferences.

It should be noted that Microsoft Word also comes with its own set of page layout tools. They might be poor compared to Pages’s feature set, but they do exist, and, out of curiosity, I tried to see what would happen when drawing a block of colour behind some text in a word document. Here’s the result of my experiment:

I did this by simply typing some text and then drawing a rectangle with a solid colour background and moving the rectangle behind the text.

If you zoom in on the text, here’s what you see:

It still looks like subpixel anti-aliasing to me!

Now, I understand that the issue here is essentially the transparency of the text iself, not the transparency of the text’s background. Word does not support text transparency (as far as I know), whereas Pages does. (If you have a block of text in Pages, you can change its “opacity” to less than 100% in the Inspector window.)

But how often will the average Pages user use text transparency—compared to the frequency of situations where he’ll be typing and reading text with 100% opacity? Surely in light of this Apple could have come up with a scheme that fully supports subpixel anti-aliasing when the opacity is 100% and then switches to standard anti-aliasing when the opacity is less than 100%!

Once again it looks like Apple has chosen to favour theoretically “cool” features such as text transparency over interface consistency and user comfort in everyday computing activities. Which is more important?

So the bottom line for me as an end user is clear: Word respects the user’s font smoothing style preference, and Pages does not. Whether there are highly technical reasons for this is ultimately of little interest to me. It’s about eye strain and visual comfort, not about Quartz compositing and off-screen rendering. My eyes’ comfort is more important to me than some hypothetical advantage with text transparency that I never use.

(Note: Apple’s own style guide spells anti-aliasing with a hyphen. So that’s the spelling I am using here. The style guide doesn’t specify whether it should be subpixel or sub-pixel, though.)

It doesn’t take too much work, however, to uncover areas where anti-aliasing does not work properly. One of those areas is the “Print” dialog box. Microsoft always has to do things its own way.

So when you invoke the “Print” dialog box in Word 2004, instead of the standard “Copies & Pages” section that you get in most other Mac OS X applications, you get a custom-designed “Copies & Pages” section that includes a “Quick Preview” of your document (as if there weren’t already enough different document view modes in Microsoft Word) and custom-designed text fields for entering the page range, number of copies, etc.

These custom-designed fields use a text font size that is arbitrarily different from the normal font size used in Mac OS X’s standard “Print” dialog. And when you select the text in one of these text fields, you get the sadly familiar white smears:

To be fair to Microsoft, this is the only place in the Word 2004 interface where I have found such problems. On the other hand, this is obviously a custom-designed dialog box, so I doubt that Microsoft can blame Apple for the problem in this particular dialog box.

When it comes to the actual contents of Word 2004 documents, however, the problems with font smoothing can be rather obvious. First of all, there are significant problems with font smoothing in the Equation Editor, which have already been documented in another post.

Then there is what happens when you use vertical selection in a Word document (i.e. when you draw a selection rectangle while holding the Option key down):

Eek.

Vertical selection is obviously a proprietary thing in Word 2004. (Apple’s own word processors and text editors, i.e. Pages, TextEdit, Mail, etc. do not support it at all.) But there’s no excuse for such ugliness in a finished product.

For example, here’s some text in Lucida Grande 11 pt in TextEdit, with font smoothing style set to “Medium” 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 “Show Input Source Name” 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 “File” and “Edit” 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.

I subsequently sent a link to the blog item to Bare Bones Software as a way to report what, to me, looked like a bug in BBEdit.

I soon received an e-mail reply from Rich Siegel, who indicated that it was a problem with the OS itself rather than with BBEdit. He expressed, in turn, his own disappointment at seeing me include BBEdit in my “Hall of Shame” for this particular problem. We exchanged a few more e-mails about the topic, and I offered to post a clarification on my blog, which I am doing now.

I am obviously not a Mac OS X developer. This means that, when a third-party developer tells me that a problem with his application is actually the fault of the OS and not the application, I have to take his word for it. In the case of Rich Siegel and Bare Bones Software, I don’t really have a problem doing so, since BBEdit is otherwise an extremely well-behaved Mac OS X application and Bare Bones Software has a long history of excellence in Mac OS software development.

As Rich indicated to me, BBEdit does support Quartz font smoothing everywhere else—and, in my original post, I certainly didn’t meant to imply that it didn’t. The “Anti-Aliasing Hall of Shame” category is usually not about Mac OS X applications that don’t support text anti-aliasing at all, but rather about Mac OS X applications that have flaws in their implementation of it.

What Rich Siegel is telling me here actually suggests that the problem with the white smears around anti-aliased text when displayed over a dark background that I have noted in various applications might in fact be the fault of the OS. I actually don’t have any way of telling which cases of white smears are due to the OS and which are due to the application itself.

Bare Bones Software is aware of the problem in this particular dialog box, and, even though it is the fault of the OS, they are planning on working around the problem and fixing this particular dialog box eventually. It’s just not a huge priority at this point in time.

I am still disappointed that the problem exists in this particular dialog in BBEdit 8 and that working around it is not a bigger priority for Bare Bones Software. After all, it’s fairly common knowledge that every version of the OS has flaws and that third-party application developers may have to work around them in order to ensure that their application works properly. (The opposite is also true to a certain extent: third-party applications can also have flaws that Apple has to work around in its own OS software updates in order to maintain compatibility.) And this particular flaw is not purely esthetic. In my view, the white smears do affect the legibility of the highlighted text.

But the bottom-line here is that, according to Rich Siegel, this particular flaw in BBEdit is due to the OS itself, and therefore the Anti-Aliasing Hall of Shame inductee should be Apple itself and not Bare Bones Software. (It also doesn’t look like Apple will be fixing this particular problem any time soon.)

I have now posted a link to this update at the bottom of the original post.

FileMaker does use Mac OS X Quartz font smoothing, and has no problem with it in regular text fields:

In this screen shot, the word “Jacobs” is in Verdana 24 pt, it has Quartz font smoothing, and even though the field is selected and the text is therefore highlighted in green, my preferred selection colour (although for some reason FileMaker Pro uses a lighter shade of my actual colour of choice), there are no white smears around the shapes of the characters.

In other words, FileMaker has no trouble rendering text with font smoothing over a darker background colour.

But that’s in regular text fields. FileMaker supports other kinds of field formats, of course, including pop-up menus, pop-up lists, radio buttons, checkbox buttons, etc. And that’s where the true extent of FileMaker’s font smoothing support is revealed:

This is a field formatted as a pop-up list. As you can see, while the actual text field is rendered properly (albeit with the lighter shade of my selection colour), the pop-up list items have a problem. They do use font smoothing, but obviously the font smoothing is not handled by the same routines as the ones used for the field itself. When the list items are displayed over a white background, there is no visible problem. But as soon as you select an item in the list, FileMaker highlights the selection with the normal selection colour (not the lighter shade this time) and… the ugly white smears around the shapes of the characters are back.

The problem is undoubtedly related to the fact that, instead of using standard Mac OS X Aqua controls, FileMaker uses its own proprietary interface controls. (The radio buttons and checkboxes don’t look anything like regular Aqua radio buttons and checkboxes either.) FileMaker has always used proprietary controls, presumably as a way to ensure cross-platform compatibility (so that databases designed with the Macintosh version of FileMaker look the same when opened with the Windows version of it).

But that’s not an excuse. FileMaker also uses its own proprietary code for drawing regular text fields, and, as we’ve seen, these regular text fields do not suffer from the same problem with font smoothing.

It’s just sloppy programming, and I am pretty sure that the reasoning here is that this is something that occurs only while you are selecting an item in a pop-up list, so it’s probably considered a “minor” inconvenience and left forever at the bottom of the “to-do” list. Unfortunately, it might be minor with the default pale blue selection colour in Mac OS X, but it’s far from minor with a darker selection colour such as my dark green. It really does affect the text’s legibility.

And the problem is not limited to pop-up lists. It also occurs in various other dialog boxes in FileMaker. The following is a shot of the “Part Setup” dialog box:

You can also see the same kind of thing in the “ScriptMaker” dialog box, in the “Sort” dialog box, etc.

FileMaker is an expensive application, and when you pay a significant amount of money, you expect some level of quality in your software. I am afraid that, when it comes to anti-aliasing support, FileMaker’s quality is simply unacceptable.

Apple’s Pages application is a prime example. It’s obviously an application that was built from the ground up for Mac OS X. Yet it suffers from a fundamental problem with font anti-aliasing that obviously only slipped through because of Apple’s own carelessness.

Take the following two screen shots:

They are two screen shots of the exact same text in a Word 2004 document with the exact same font (Times New Roman 11 pt) and zoom (150%) settings. The only difference is that the first one was with the “Font smoothing style” setting (in the “Appearance” preference pane in System Preferences) set to “Standard – best for CRT,” and the second one was with the “Font smoothing style” setting set to “Medium – best for Flat Panel.”

In other words, Word, for once, is a well-behaved Mac OS X citizen and uses the font smoothing style chosen by the user in System Preferences.

Now if you try the exact same thing in Pages, here’s what you get:

Can you see a difference between the two samples? You can’t, because there isn’t one. Regardless of what “Font smoothing style” setting is selected in the “Appearance” preference pane in System Preferences, Pages always uses the same font smoothing style, and, as far as I can tell, it is the standard “best for CRT” style.

There is no excuse for this. Apple makes both the OS and Pages. They, of all people, should comply with Mac OS X’s standards and respect the user’s preference.

I’ve reported this bug to Apple and they have acknowledged that it is a problem and said that they are “working on a solution,” but of course it could be months before a Pages update is released.

Even then, I won’t be surprised if you have to upgrade to Pages 2.0 (at a price) in order to get the fix. The Pages 1.0.1 and 1.0.2 updates that have been released so far did not fix this or indeed any other significant problem with Pages that I am aware of and have reported on in this blog (under the “Pages” category). If Apple really wants more people to embrace Pages as an alternative to Word or as a replacement for AppleWorks, they’d better start showing more commitment to the application soon.

Sadly, the answer is yes. Anyone who edits web pages with BBEdit can see it. Just open a web page and bring up the “Anchor” dialog box:

Yup. Even Bare Bones Software. After all these years. In such an obvious location. It’s sad. And it just shows how common the problem is in Mac OS X. (Clearly in this case it’s a problem with classic Mac OS code that hasn’t been properly updated.)

UPDATE: Please read “Anti-Aliasing Hall of Shame: More about BBEdit and Mac OS X.”

All you have to do is install the latest version of MacLinkPlus Deluxe (or any previous Mac OS X-native version) and drag a file to its main window. Here’s what you get:

I think it’s fair to say that, as far as legibility is concerned, this is breaking some kind of record, even within the group of honourable Anti-Aliasing Hall of Shame inductees.

And it’s not like DataViz is not aware of the problem. A couple of years ago, I wrote a review of the product (version 14 at the time) and was actually able to discuss the issues with a DataViz staff member. He fully acknowledged the problem—but obvious, two years later, they still haven’t done anything about it.

The product has quite clearly been stagnant for the past few years, and it is just a clear that DataViz’s priorities lie elsewhere. It’s hard to tell whether we’ll ever see a version of MacLinkPlus Deluxe with proper font smoothing.

The reason I chose this product when I was looking for a replacement for iPhoto can be summed up in a single word: performance. Where older versions of iPhoto (I haven’t seriously tried the most recent ones) would start choking as soon as my photo collection grew to two or three thousand pictures, iView Media Pro remained perfectly usable with four, five, six, etc. thousand pictures.

It was also able to produce HTML slide shows of various collections of pictures, with far more flexibility than iPhoto and the .Mac service.

I have been quite disappointed with the evolution of the product in recent years, however. For one thing, the price has crept up significantly. The 2.0 upgrade was a major disappointment in that the focus appeared to be on bringing the Windows version to feature parity, removing some features from the Mac version in the process. And there were significant problems with performance—one of the key benefits of iView Media Pro over a consumer-level tool such as iPhoto—which were reduced in subsequent updates, but not completely eliminated. (I also still find the interface significantly sluggish in Mac OS X 10.4 compared to what it used to be in 10.3.)

But the reason I am including it in the Anti-Aliasing Hall of Shame is that iView appear to have no interest in embracing Quartz font smoothing. It is used in the interface elements that are controlled by Mac OS X, of course. But it is not used at all in the interface elements that are specific to iView Media Pro.

Worse still: As far as I can tell, the software does not use any anti-aliasing at all—not even the old (admittedly rather poor) anti-aliasing from the classic Mac OS. Consider the following screen shot:

As you can see, the “Thumbnail” tab heading has proper font smoothing, as does the file path underneath it. But the file name underneath the actual thumbnail has no anti-aliasing. It’s in the exact same font (Lucida Sans, 10 pt), but it a plain bitmap version of the font, which takes you straight back to the classic Mac OS circa version 7.

The same problem applies to the left-hand side pane, which has two modes (“Info” and “Organize”). In both modes, the font used is Geneva 9 pt without any font smoothing—and, as far as I can tell, there is no way to change that font:

In Mac OS X 10.4, this is positively anachronistic. I don’t think I have any other application that still doesn’t support at least some form of font smoothing, and still forces you to use Geneva 9 pt.

Finally, in areas where iView Media Pro does use font smoothing, such as its various dialog boxes, they haven’t implemented it properly, and it suffers from the usual ugly white smears, which are particularly visible with a darker selection colour:

With the price that iView charge for this product, they certainly could afford to implement Quartz font smoothing properly!

In Mac OS X’s Help Viewer, do a search that will return results that are part of the iTunes help pages. You’ll get a list of results that look like this one:

It might not look like much, but when you blow it up, you get this:

Not pretty… As noted in the original blog post, this particular problem is due to a poorly masked icon. In other words, the problem is not with on-the-fly anti-aliasing in Help Viewer, but with the mask associated with the existing anti-aliased iTunes icon used by Help Viewer.

It’s still an anti-aliasing problem, and it is still shameful that, today, in October 2005, with Mac OS X 10.4.2, iTunes 6.0, and Help Viewer 3.0, we still have to face such ugliness on our monitors.

For what it’s worth, the iTunes icon has the proper masks elsewhere in the system, since the same small icon has no problem with a dark background in the Finder:

As far as I know (even though I am not a Mac OS X developer), there is no excuse for this. Mac OS X comes with built-in support for high quality anti-aliasing, and all Mac OS X developers should, by now, updated their software so that it makes full use of Mac OS X’s built-in technology.

Yet, there are still numerous examples of software titles that have not been updated. Here the first one, courtesy of—who else?—the big bad software company from Redmond:

As indicated in the screen shot itself, this is a table cell in Excel 2004 containing text in Optima 14 pt with a zoom setting of 100%, and with “Quartz text smoothing” enabled in Excel’s preferences. This is what happens when you select the text in the cell.

Of course, I use a (relatively dark) green colour as my selection colour, as opposed to the default pale blue option in System Preferences’ “Appearance” preference pane. But that shouldn’t make any difference. Mac OS X is perfectly capable of doing proper font smoothing over a darker selection colour. And Microsoft is perfectly capable of doing this properly in its applications, since there are no problems with the same font and the same font size and the same selection colour with text in a Word 2004 document.

It’s just that Microsoft still has not bothered to update its Excel code to do font smoothing properly in Excel table cells as well.

It’s inexcusable, and it’s shameful. And I am going to post more examples of this by many other software companies (including Apple itself!). Still, I am sure you will agree that Microsoft deserved the opening salvo here.