What is interesting is whether you are willing to concede him the point or not.

It's not really my point to concede. This isn't really WebCore code (it's in the layer underneath WebCore).

As I mentioned in the comment Gruber quoted, Safari's current policy isn't exactly intentional, but rather a side effect of the APIs we're using. Those APIS always seem to measure using outline versions of the fonts anti-aliased (and that's how they render as well). Even when anti-aliasing is turned off, outline fonts are used instead of bitmap fonts.

Comparing to Camino is, I believe, not a fair comparison, since when it comes to text rendering (and this is going to sound confusing, but it's true), Camino is not a Cocoa app. Camino uses NSQuickDraw views, which are Cocoa objects upon which you can draw using Quickdraw.

I do not believe that Quickdraw's default rendering policies and Quartz's default rendering policies are the same, but I could be wrong. I am not really a Mac expert, so I don't know for sure.

A more compelling point is that Safari's rendering does not match that of other Cocoa apps, and that seems wrong to me. I do certainly agree that pure Cocoa apps (this excludes Camino) should be consistent in their rendering of fonts on the OS, and that OS settings should be obeyed.

However, I would be concerned if honoring the OS settings by using the higher-level CG APIs carried with it any sort of substantial performance penalty.

BTW, I should reiterate that I might not have my facts straight here. Mac font rendering is most decidedly not my area of expertise, so don't quote me assuming I'm necessarily even right. I might not be. :)

Uhm, the anti-aliasing issue is an issue. I hope it's treated as a bug.

> I do certainly agree that pure Cocoa apps (this excludes Camino)
>should be consistent in their rendering of fonts on the OS

I can't see how it should make any difference if it's a Cocoa app or a Carbon app. If it's a native Mac app, it needs to be consistent and respect global user settings.

In spite of my near dogmatic affinity for anti-aliasing, John Gruber has some good points. While I do love anti-aliasing, I love consistency even more.

Mr. Hyatt, I trust you will pass these issues along to whoever at Apple is resposible for this sort of thing. If the APIs are to blame, they can be changed. IMHO opinion, consistency is the single most important advantage that the Mac has over other OSes, and while I dearly love OS X, it has lost a little ground in this area.

Gruber's article is very effective in that it addresses the actual problem with Safari (the API's) rather than launching a salvo against Safari itself. Regardless of the cause, the problem(font's being anti-aliased despite the designer's desire for them not to be) is a bug and should be treated as such.

Again, consistency is the issue here - consistency with the OS, consistency with other browsers, consistency with the general concensus that should be adhered to when rendering fonts anywhere.

Designers make certain choices regarding font selection and size based on how they are anticipated to be displayed. In other words, I chose Geneva and sized it a certain way so that it would perfectly fill the link bar at the top of my weblog (Hivelogic), as mentioned in Gruber's article.

This technique works fine in just about every browser (including browsers running on Windows and Linux) except for Safari. While the browser might not be to blame (the API's are), it bodes poorly for Safari, which is otherwise the best thing since morning coffee.

Who uses Geneva and Monaco in websites anyway? They're Mac-only fonts. These don't exist on PCs, so for 95% of the web browsing world this whole argument is irrelevant. They'd be replaced by Courier or other ungodly fonts in Windows/Linux land.

As for Quartz's anti-aliasing, there's more to it than just anti-aliasing the text. Quartz has two things in its text rendering algorithms - Quartz text smoothing and Quartz text metrics. You need both (fortunately, cocoa apps use both) enabled to get optimal results. The only place this runs into a problem is in Carbon apps, though since OS X 10.1.5 (where both options were made available to Carbon apps) this again has been irrelevant since most people have updated their apps (Internet Explorer, for example, only supports smoothing but uses QuickDraw metrics, which is why text looks like ass in it). If not, you can force it with Silk.

The idea behind Quartz Metrics is that it can use fractional widths to space fonts on screen. This is unlike QuickDraw or Windows' GDI+. It's a huge benefit of OS X, but it's also more of a forward-looking technology, as it's resolution independent.

Just some background info, is all.

Dan, so it is actually the metrics that is messing up some deisgners and not the aa?

Off topic, I love Safari's bookmarking feature, I've never bookmarked so much, so fast, so furiously-all nicely organized in folders.

I read the last article too, but.. to me.. in almost every case where he says Safari looks ugly, I think Camino is the one that looks ugly. I like anti-aliased text - EVERYWHERE. And I'm glad Safari is the way it looks.

"Dan, so it is actually the metrics that is messing up some deisgners and not the aa?"

Since these fixed width fonts (Monaco, Profont, Courier, etc) that are being antialiased are, well, fixed width, it should be irrelevant as far as spacing goes. However, the fixed widths can still be fractional, unlike a, say, one pixel fixed spacing. This is where some of the grayscaling in small-sized text in Mac OS X comes in to play - it's trying to make up for a lower resolution display.

The idea behind using fixed-width is that it's a known-good thing - you can put in spaces and tabs and know exactly where things will align, unlike proportional fonts. Proportionally spaced fonts will be, well, correctly spaced under Quartz as Quartz in its past life was Display PostScript. Steve Jobs and co. used Display PostScript to create the next level of WYSIWYG for resolution-independent displays. It was like having your screen be as accurate as a laser printer, essentially. Display PostScript was a DSP-accelerated version of what is now today's Quartz, or Display PDF. NeXT has had these smooth fonts for years. The web was developed on a NeXT. What does Mr. Berners-Lee think about this? Just some food for thought and more background info on OS X's text rendering (which, for all our complaining here, is a bazillion times better than what Windows or OS 9 could do).

I must say, I thought John's article was very interesting as well. However, Dave's point about Camino using NSQuickDraw vs Safari using Quartz sounds dead on. While I haven't done any Cocoa, I did do a lot with Quickdraw back in the day. QuickDraw (among other major limitations) can only render to the pixel - no fractional widths. This ends up mucking with the font rendering. The ultimate result is that no matter what improvements you make, QuickDraw text rendering will never have the same metrics as Quartz (unless you worked extremely hard to bastardize Quartz).

Now, it is a *very* interesting point that Safari doesn't behave the same as other Cocoa apps. Dave, I'd chat with the OmniGroup a little bit and see if they know anything on this issue. I think they'd be receptive, since they've stated they're going to use WebCore in the future, and they certainly don't want to inherit "bugs" like this.

Just as in Windows, there should be a preference option as to whether you want your fonts aliased or not, particularly for fonts under 12 points. This should be addressed at the system level and browsers should not try to supersede the system, especially if they are aligned with the company who created the system—performance deficit or no performance deficit.

It's a states rights vs. federal rights issue. States (applications) should obey the authority of the federal government (operating system).

Where John complains that Safari looks worse, I think it looks significantly better. In fact, one of the reasons I like Safari so much is that its text rendering is noticably better than, say, Mozilla. Way, way better.

I see his point that it's not honoring preferences. However, if this is "fixed", I would very much like to have the option to un-fix it via preferences, and the CSS stuff sounds pretty good too.

i had been using chimera/camino as my default browser since .2/.3 before safari came about. the first thing i said when i launched safari was "wow, that starts up fast". the second thing i said was "wow, that text looks beautiful". i'm getting into the subjectivity area again here, but all of gruber's examples except the silkscreen one looked better in safari. i may be mistaken, but don't cocoa apps actually use a different approach to implimenting aa than carbon ones? i know that there is debate as to whether to use ATSUI (i probably got that wrong) font rendering in camino to make it's text look better, and if you've tried silk, you can see that it's AA looks different than that of a cocoa app (look at text in appleworks with silk and textedit). also, if a speed increase can be had at the expense of antialiasing monaco 10 (which doesn't look bad AAd anyway), i'd say use it. keep on doing what you're doing dave, it looks great

"I can't see how it should make any difference if it's a Cocoa app or a Carbon app"

They don't use the same Drawing engine. Just look at Carbon software, most of the time you can see artefact when selecting the text, it's a dead giveaway that's it's Carbon not Cocoa.

I agree that a font without an outline should never be antialiasing, that's why when I design a site with aliased font, I do images, it's the only really safe way to preserve the font.

I do think that Safari as the best looking rendering, I use like OmniWeb for it's rendering, I switch to Camino with is way better at standard but awfull at rendering OS X widget.

We've got two bugs filed on Safari based off John Gruber's article and off the discussions in this blog.

(1) Safari is using outline fonts instead of bitmap fonts when rendering to the screen (e.g., Monaco 9).

(2) Safari is not obeying the global OS antialiasing settings.

AFAICT, those are the two bugs that have been exposed here.

To Dan Vincent, who said "Who uses Geneva and Monaco in websites anyway? They're Mac-only fonts. These don't exist on PCs, so for 95% of the web browsing world this whole argument is irrelevant."

This is true, of course. Fortunately, CSS allows us to specify alternate fonts (such as Arial or Verdana) which work just fine on Windows systems (and are correctly not aliased by most Windows browsers).

So, while Mac users get the best visual experience, Windows users get the next best thing.

To the other Dan ;)

Yes, I understand that, but even as a Mac user, I usually stick to the largest denominator when designing sites. I'd rather be consistent (ah ha!) than substitute fonts. I guess that comes from my background as a print designer.

>>I can't see how it should make any difference if it's a Cocoa app or a
>>Carbon app"
>They don't use the same Drawing engine. Just look at Carbon
>software, most of the time you can see artefact when selecting the
>text, it's a dead giveaway that's it's Carbon not Cocoa.

I know that they can use differnent drawing engines. That's not the point. As the user of a Mac (and it is, after all, still a Mac), I should not have to worry about what kind of application I run. They should all just behave consistently.

"I should not have to worry about what kind of application I run."

Unfortunately, until all application are written in Cocoa, it wont work that way. You even have software that use their own version or antialiasing/drawing, all major Adobe Software use a proprietary drawing engine base on PDF.

Regarding mac-specific fonts. I share Dan V's views when designing sites that consistency is better than specificity. (Although there ARE windows versions of ProFont out there.)

However, I could imagine that some largely-visited sites like Apple, VersionTracker, Macintouch, etc. who have a predominantly MacOS audience would find it beneficial and desirable to use certain Mac-only fonts.

And FWIW, for every font other than ProFont 9pt, I prefer anti-aliasing. I prefer the way VersionTracker looks in Safari over Camino.

I bought an 17" iMac recently. I was shocked when I started using Safari to browse the web. The text looked all blurry, especially the small font-sizes. Moreover, in many places, the small font text had *RED* in it instead of all black (and the gray that I expect would be used for font-smoothening)!!! The small font blue-hyperlinks also look messed up! I guess this is a result of font-smoothening or anti-aliasing or whatever it is called.

I was stumped as to why I had not noticed this in the apple store. I even went back to the store to check out the computers there to see if they had the same problems. They did. I guess I never noticed it before because I was mainly playing with the iLife apps. I went back home and logged a bug via Safari. I am glad to see this discussion, and that similar bugs have been logged.

There was a post earlier talking about Display Postscript on NeXT. I have been a big-time NeXT fan since 1992 (when I first saw/used one) and is the main reason I switched to the Mac platform. I did not see this kind of problem on the NeXT. I guess this "problem" is a result of switching from postscript to pdf (but I could be wrong). PDF files in acrobat reader on Windows also looks all blurred.

In the examples comparing Camino and Safari, when I sit back and *look* at the Safari text (like I would look at a picture), it looks beautiful compared to Camino. However, when I try to *read* the text, it looks all blurry, and Camino looks clearer.

When I browse with Safari, the small fonts really hurt my eyes. I have to make the fonts really big in order to reduce the blurriness.

I hope Safari is fixed so that it honors the general system preferences setting that turns off font-smoothening for small fonts. Also, I hope an option is added to turn off font-smoothening completely (I would like to see for myself how it would look when turned off for the big fonts as well).

Deepak: Quartz can use subpixel font rendering in Janguar. It's a huge improvement over the standard AA, but I have to set it to "strong" in order for it to not have a huge color fringe.

If you don't like subpixel rendering, you can change it back to "Standard (Best for CRT)" and get normal Quartz font smoothing back.

Dan: Thanks for your response. When I change the font size at which to turn off font smoothening, I can see a difference in the way text appears.

However, when I change the font smoothening style (Standard, Light, Medium, Strong), I cannot see a difference. Even when I use the DigitalColor Meter application to see the pixels, I see no difference. Even with Strong, I see color-fringing.

What sort of difference am I supposed to see between the various smoothening styles? What is the best way to observe the differences?

Thanks in advance.

Dan Vincent: "Yes, I understand that, but even as a Mac user, I usually stick to the largest denominator when designing sites. I'd rather be consistent (ah ha!) than substitute fonts."

But, you see, Geneva was designed to look good at 9pt on a Mac; Arial looks like crap below 11pt (ever see Arial 10 bold on a Mac? can't see the bold).
Thus if I spec any sans-serif type for small (9pt-ish) sizes, I spec it as Geneva,Arial,Helvetica.

As for Monaco, I have recently, after doing a lot of testing, decided to leave that up to the user; I now use TT or PRE without specing size, and if the user wants their TT/PRE as Monaco or ProFont 9, they can set their browser for it; I no longer try to set it for them.

-Walter

I read the last article too, but.. to me.. in almost every case where he says Safari looks ugly, I think Camino is the one that looks ugly.

Anti-aliasing is good in the majority, but should I not WANT my site to render the fonts like that, then I have should have to option to turn the damn thing off!

Especial from a design point of view, this can be very restricting from time to time.

Roll on CSS3 and supporting browsers.

cool article