October 26th, 2005 • 4:19 pm
Last week, I posted an item in my “Anti-Aliasing Hall of Shame” about BBEdit. I indicated at the time that I was disappointed that even such a well-behaved Mac OS X application suffered from a problem with anti-aliased text, in a fairly obvious location (the “Anchor” dialog box frequently invoked when authoring web pages).
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.