i would personally LOVE that ability!!

That would be great!!!

One part of John's article that you didn't adress: *Safari's treatment of bitmap fonts differs from that of standard Cocoa apps*... consistency throughout the system is important!

that would be SWEET!

Is anybody else having issues getting to MSNBC.com the last 2 days using Safari? It starts to load, but then dies... Camino it works fine, and obviously Internet Exploder gets to it fine, but Safari just doesn't get there anymore. Strange no?

I agree, the anti-aliased versions look better to me, but it's pretty subjective. The font-smooth property would definitely be an awesome feature. I don't suppose any other browsers support it yet though, do they?

There's no reason not to.

Seems like that should be a system-wide preference setting. Oh, wait - it is already. I like the flexibility Adobe Acrobat Reader gives you on the CoolType preference settings, but it seems very un Mac-like to provide that level of granularity in each application. Better would be for Apple to expand the range choices in the System Preferences application.

Great-- I'd love to see this. Font smoothing sucks for tight type.

On an unrelated note... ever since I've been using Safari, I've been seeing all these "site icons" in the URL bar. How do you code a page for that? What's that called?

Matt

As the guy who made the page that John took the snapshot of (hivelogic.com), I can say that I intended for the font to *not* be anti-aliased.

In fact, that was why I chose the typeface in question (geneva) and that size (9px) - primarily because geneva 9 is a bitmap font, designed to be displayed without any aliasing.

While I think the ability to control aliasing behavior is nice, it seems odd that I should need to modify my CSS (which works well in most other browsers, across platforms no less) in order to force Safari to behave correctly.

You use the term "correctly", but this is subjective. There's nothing wrong with antialiasing Geneva.

To D. Benjamin, the subjective nature of the question of when antialiasing is good or bad pretty much means that this is not a question of Safari working correctly or incorrectly. I like my fonts antialiased across applications and media, except for the Terminal.app. Thus, from my perspective, Safari is working correctly as is, and not antialiasing 9px Geneva would be incorrect -- regardless of whether or not you as a webmaster want to push aliased 9px Geneva on me. That's why these things need to be not only definable on a per-webpage-basis but also overridable by the user. Both of these goals can be accomplished through CSS.

Fixed-width fonts like Courier get much lighter with antialiasing.

For those of us who would like to have our spouses use Safari instead of IE to read their Yahoo! Mail (which uses fixed width text), it would nice to be able to specify from the Appearance preference that the fixed width font should or should not be antialiased.

To Matt W -- google for 'favicon.' Browsers look for a favicon.ico in the root folder of a website for those little site icons.

It's pretty hard to argue that the Perl code, at the very least, should be antialiased. It's just a huge difference in readability, and is especially distracting in a language which already looks like line noise.

For the Geneva example, to my eyes it is clearly wrong to antialias the typeface, because too many of the verticals are being made "thinner" by the antialiasing -- look at the first "H", or the first leg of the first "M".

There are also points on the "C"s and "O"s, at the top and bottom, that are actualy dropping out. The "O" in "SOFTWARE" could be two parenthesis, "()" -- do you really not see this? Do you really not think it looks bad?

The horizontal spacing of the entire line is also wrong -- the web site designer clearly set it up to go from the beginning to the end, whereas Safari is indenting the begining, and finishing before the end. (Now, maybe there's better ways to accomplish that, in HTML/CSS, but Camino is displaying it as intended...)

I think it comes down to, was the face fundamentally designed with antialiasing in mind. Monaco clearly was not. And I don't think Geneva is, either, at least not at smaller sizes.

Hoorah!

Non-AAed type may look better by itself, but when situated next to AAed type, it looks bad.

I'll take your word for it that it's subjective, but the AAed Safari display of Genevea 9 looks *much* better than the unAAed Camino version!

Does the font-smooth property allow specifying specific *typefaces*, rather than just point sizes, to disable/enable AA on?

I think John's right about Monaco, & it probably shouldn't even be AA at 12pt (i use an ibook with its tiny pixels). The small Geneva is prettier AA, i agree with you, but it's noticeably smaller as well (looks a full point shorter), thus harder to read.

Perhaps MacOSX should automatically enlarge AA fonts a bit, as this AA-shrink is a common problem i find. (Not your department, i realize;)

I would be great to have ability to control smoothing from CSS or at least from Safari Preferences. Personaly I like much Geneva without antialiasing - well it is also dependent on monitor. Other fonts I like to have antialiased...

That feature would be welcomed...

Regard
Ondrej

I think what needs to be realised is that while fonts may look 'nice' anti-aliased, there are certain fonts that were designed never to be anti-aliased.

Anti-aliasing is a trick, something to simulate how a typeface looks when printed. Thus, fonts such as Helvetica, Palatino and Arial look great when anti-aliased, especially at 12 point/pixels or above.

Macintosh fonts such as Genva and Monaco were desinged with a specific purpose - to be legible on low-res screens without any anti-aliasing. They were made for this, and they absolutely work perfectly aliased at 10 or 9 pixels. Anti-aliasing results in a blurry smudge which I find it very hard to belive anyone could find more pleasing to the eye.

By all means fonts desinged for print, and fonts displayed above at 11 pixels or above can be aliased, but please don't force us to have look at endless blurry lines of 9/10px Geneva or Monaco.

Just look at apple.com in camino/IE and the way they have used Geneva for small type to be perfectly legible without anti-aliasing.

... agree, but this not problem only in Safari, at the end somebody at Apple UI group should think about system wide preference which font should be antialiased and which not... this would be right solution.

If this will be implemented in Safari only - OK at least something.

Ondrej

OS X as whole is shit at handling aliased fonts 10px or below. There is well known bug that has been documented on this. But back to Safari, IE and Mozzilla based browsers accept that Monaco and Geneva should never be anti-aliased. This is not subjective it is the way they are designed to be viewed.

Safari anti-aliasing these fonts is like putting a huge spolier on an Audi TT just 'cause some people who don't understand the way it was designed may think it looks nicer.

Ok, just to clear things up (having worked on Moz/Camino before switching to Safari). Camino/Moz get this right by accident, not by design. Camino and Mozilla use Quickdraw to do rendering, not Quartz, and that means that bitmap fonts like Geneva and Monaco just don't get AA.

Safari uses Quartz (CoreGraphics calls), and CG doesn't use bitmaps when rendering fonts, which means even with AA off, the fonts don't look the way they do in Quickdraw anyway.

Maybe this is a deficiency of CG when compared to QD. I'm not an expert, so I don't know for sure.

I guess my point is that rather than talking about what Safari or Camino are doing right or wrong, it would be better to focus in on what CG and QD are doing right or wrong, because ultimately both browsers are just using the underlying OS primitives.

Thanks for clearing that up. I really hope apple recognise that not all fonts should be anti-aliased.

Um, why again am I using non aliases fonts on a $3000 computer? So what I read will look like it came from a typewriter? I use a computer because the fonts are smooth and easy to read. YMMV

Cheers.
Mike

If fonts like Geneva and Monaco had better hinting for small sizes it wouldn't matter if they were aliased or anti-aliased anyway. Ideally, all fonts should be anti-aliased, but should have good enough hinting to be as readable as possible at any size. This was the promise of Truetype, but very few fonts have taken full advantage of it.

Mike, you may have spent a $3000 on a compouter but a monitor cannot go much higher than 100 dpi.

Thats why bitmapped fonts were designed the way they were in the first place, to be legible on a computer screen.

Try spending £5 on a well designed and printed publication if smooth and easy to read is your goal

[You use the term "correctly", but this is subjective. There's nothing wrong with antialiasing Geneva.]

There is, if Apple provides a mechanism to a user that says "Turn off text smoothing for font sizes X and smaller." [System Preferences | General] yet your application doesn't follow that setting. If the reason that your application isn't following that setting is an API thats out of your control then that's fine, work with the creater of the OS and try to get the API fixed.

I do also have to go on the record and say that blaming it on the API is suspicious. I just now switched this setting to 12px and (with a restart) every application I'm running besides Safari picked up the change (moz, NNW, Snak, Fire,IE...).

Regardless of where the problem lies, I don't think relying on not yet official CSS porperties is the answer. CSS3 may (will) someday provide for a method to more explicitly express the authors wishes when it comes to font-smoothing, but as with all CSS the user still would have ultimate control.

In my opinion, ALL fonts look A LOT better antialiased ALL of the time. Yes, this includes source code (I am a programmer) and the terminal. For me, smoother lines are easier to read, period. I respect that some people prefer aliased fonts, but to me they look like crap, regardless of the font, size, or context.

Let me add that I think in all cases the choice of aliased vs. antialiased fonts should wholly under control of users, and not of authors.

Similarly, I think that clicking the Back button should NEVER consult the server, regardless of what the author says. When I click back, I want to see exactly what I was just looking at, dammit, not an updated version. Any browser that implemented an option for this kind of behavior would win me over.

Korean text smaller than 14 or 16 points is much more readable without antialiasing, look at Windows XP's Internet Explorer.....

It is interesting that there are so many divergent points of view on this - it suggests among other things that there is a wide variety of use of text. I spend a lot of time looking at code, and have found after (too) many years that monospaced fonts provide the most clarity. I have also found that color combinations as well as typefaces are important - wherever possible I try to put dark blue text over the top of an off-white background. On the other hand, if I am reading text which is not code, aliased proportional serif typefaces in black on white do it for me. Readability of text is in part a learned skill, and what is readable is shaped a great deal by our experiences.

As an aside, I just found a bug - when this popup window popped up, the bottom edge of the 'comments' text field was below or coincided with the bottom edge of the window. When the text filled the visible space, and the comment field started to scroll, little black marks showed up in the window frame. I'll send that to Apple.

"Macintosh fonts such as Genva and Monaco were desinged with a specific purpose - to be legible on low-res screens without any anti-aliasing."

Does anyone know if this is true? I know they were designed for legibility at small point sizes on computer displays but were they really designed to *not* be anti-aliased? Anti-aliasing only seems to have hit in the last decade or so (although I assume the concept has been around much longer)...10 years or more before said fonts were designed.

Dave,

Is there an example of another application using CoreGraphics which antialiases 9-pt Geneva -- that is, displays Safari's behavior? Because, apart from all the background noise about what's the "right" or "preferred" behavior (i.e., it seems to be an undecidable debate), this seems to be the question at hand. People seem to be asserting that Safari is _not_ acting as other apps using the same underlying OS primitives do.

And that might be why Safari doesn't seem to implement the System Prefs -> General user option as well. At the very least, implementing this option at the app level when it's already available systemwide would require some explanation/justification as to why it would be useful to have a special setting for a web browser ("I browse lots of perl code online, but like to write poems in TextEdit in 9-point antialiased Geneva," for example).

On a side note, I miss em dashes. Thbbt.

i would say that susan kare's work at creating LEGIBLE bitmap fonts would indicate that they were meant to be aliased. at the time Geneva and Monaco were designed anti-aliasing was not an option on the screen.

personally i have always liked the ATM treatment of Type 1 fonts on OS 9, which was anti-alias except at sizes where a specific bitmap font is present. which allowed me to see chunky Geneva 9/10 ( i love it ) but to smooth fonts that were intended for print.

Dave,

Is there an example of another application using CoreGraphics which antialiases 9-pt Geneva -- that is, displays Safari's behavior? Because, apart from all the background noise about what's the "right" or "preferred" behavior (i.e., it seems to be an undecidable debate), this seems to be the question at hand. People seem to be asserting that Safari is _not_ acting as other apps using the same underlying OS primitives do.

And that might be why Safari doesn't seem to implement the System Prefs -> General user option as well. At the very least, implementing this option at the app level when it's already available systemwide would require some explanation/justification as to why it would be useful to have a special setting for a web browser ("I browse lots of perl code online, but like to write poems in TextEdit in 9-point antialiased Geneva," for example).

On a side note, I miss em dashes. Thbbt.

Crap. Sorry for the double-post (he posted).

Rather than arguing over the tangent re: whether font face X or Y subjectively "looks better" smoothed or not, or whether olde-skoole bitmapped fonts should be AA'd at all, I think we should refocus on the particular, primarily functional issue raised by Gruber which Hyatt referenced in opening his original blog post on this subject. To wit:

Monospaced fonts are most typically used/spec'd in webpages for a functional purpose, viz. for clearly character-legible presentation of source code syntax (e.g. HTML, Perl, *nix shell, etc.) or for plaintext email (e.g., Yahoo! mail). AA'ing such text, particularly as size diminishes below a certain (somewhat subjectively arbitrary) threshold, can obfucsate much of the distinguishable legibility of many monospace characters, a particularly crucial distinction in the case of presenting source examples.

I respectfully suggest that Safari should default to non-smoothed display of, say, 10pt/px or smaller monospaced fonts, particularly when such fonts are at least implicitly called for or specified by text containment in TT, PRE, CODE, or SAMP elements (or any other elements conventionally spec'd for monospace display which may have slipped my mind %^).

A separate consideration involves whether or not to also smooth monospaced fonts called by name (e.g., in CSS or archaic FONT elements' FACE= attributes) but not implied-by-spec by use of the containing elements noted above. I might suggest not bothering with this trickier issue of apparent consistency; authors should use the proper structural elements when they want to display source in a non-smoothed monospace font (vs., say, simply declaring monospace font face names in an arbitrary class or for other elements), which mode of non-smoothed rendering is effected by implication in using those particular structural elements.

As for the separate issue of smoothing other, more generically bitmapped (but not necessarily monospaced) font faces, or the even more general issue of whether to smooth fonts at all below a certain size, that seems more a matter of individual aesthetic preference. IMHO, Safari should respect user preference for minimum font-smoothing size by respecting the minimum set in OS X globally by the user, and perhaps further refinable via font-smoothing declaration in a user's own CSS and in authors' own CSS (but only when CSS3 eventually provides for this as a standard) -- leaving only the question of cascade-order and how/under what conditions one should override another.

FWIW, I much prefer Andale Mono over Monaco -- about the only M$Produkt I care for at all (but then again, they got it from Monotype, so it wasn't really their baby to begin with. %^)

(Aside re: bespoilered Audi TTs -- IIRC, Audi itself added a modest ducktail spoiler lip to all later TTs because of a late-breaking problem they'd discovered with insufficient rear-end aerodynamic downforce at speed; they may even have issued a recall for the original run of spoiler-free early TTs because of this problem. Yes, I agree it sullies the original's clean design somewhat, but at least they tried to make it consistent with the overall design as tastefully as possible, and for valid reasons of ensuring safe and predictable high-speed handling. Just setting the record straight. %^)

Arthur: "a monitor cannot go much higher than 100 dpi"

That was true in the past, but 200dpi monitors are available from IBM, Viewsonic and others. Just the thought of reading 9-pixel text at that resolution gives me a headache.

If you look at AA from a signal fidelity point of view, I think the arguments a little easier to see.

When anti-aliasing a Postscript or TT font, the question is how to reproduce an analog signal (a continuous curve) on a discrete quantized device (pixels on a screen) as accurately as possible. If you just pick certain pixels to fill in black and others to leave white, you can get close. If you add percentages of gray you can get closer. Of course, doing true signal reproduction anti-aliasing is expensive, and most OSes cheat and just approximate what might look "smooth", which can add its own degradation to the signal. In addition, at very small sizes there is no reproduction that doesn't add significant error, and it all boils down to subjective tests as to what is "clearer."

However, when you start with a bitmapped graphic, you CAN display the input signal exactly. There is no interpolation or gray scale needed to reproduce the signal with zero error. Some would then argue that anti-aliasing a bitmapped font is "wrong". But the real question is, what is really the input signal? If you assume that the bitmapped font is a "crude reproduction" of some more ideally drawn font, you can guess at the proper anti-aliasing by adding gray in rough areas where it was likely that black and white were unable to approximate it. But if you assume that the bitmap font was intentionally drawn with all its pixels in the right place, then any anti-aliasing degrades the signal.

So that's a nice, semi-technical description of why you're both right. :) And when it comes down to it, a nice, simple control in an Appearance control panel that is obeyed by Safari seems like a nice compromise to me. Maybe someday a system-level control that lets you turn it off for certain fonts, or all bitmapped fonts, would make everyone happy.

As Brian W mentioned above you fail to answer the most correct analysis of John's

What?s so puzzling about Safari?s behavior is that Cocoa applications, by default, do not apply anti-aliasing to Monaco 9 or 10. Try it in TextEdit or Project Builder, if you don?t believe me.

The inconsistency which is beginning to plague the UI of Mac OS X needs to be squashed here and now. Regardless anti-aliasing monospaced fonts is a smack in the face of the historical handling of computer typography.

I'm gonna have to place a vote *FOR* antialiasing them. I think that the Perl code he cited looked better in my copy of Safari than in Camino.

Then again, I'm really good at reading small text. I'm the only person I know who can read text on my 1280x1024 17" monitor from a distance of 6 or 7 feet. Maybe I'm just weird.

The issue of bitmapped fonts (i.e., how to display Geneva "correctly") is what I was referring to when I mentioned the issue of CG vs. QD.

The problem of not obeying the OS setting is actually Safari's fault, in that we actually measure text using lower level CG APIs than the more commonly used (and recommended) CG APIs. These lower level APIs do not look at the OS setting, but they are faster (especially for measuring), and so ultimately we gained speed but at the expense of honoring the OS setting.

This is actually making even the implementation of font-smooth difficult, since once I turn AA off, I'm still measuring as though AA is on.

I think we need to cut out some religion here. Personally, I prefer anti-aliased fonts. I also prefer a contol to turn off anti-aliasing at certain thresholds, monospaced or otherwise.

But, Apple provided a TrueType version of Geneva and Monaco as early as System 7 in 1992 (read: built with vectors, scalable to any resolution, and ready to antialias whenever). All this business about how Geneva and Monaco weren't meant to be anti-aliased just isn't true.

That's great.
Are there any plans to support other bits of CSS3 as they develop? The very Aqua-esque Opacity and hsla() colors seem to me to be good candidates (the fact that I want my webpage to display those has something to do with it, too).

brain said:
"personally i have always liked the ATM treatment of Type 1 fonts on OS 9, which was anti-alias except at sizes where a specific bitmap font is present. which allowed me to see chunky Geneva 9/10 ( i love it ) but to smooth fonts that were intended for print"

this IS the correct way to handle fonts. use the bitmap if present. if not, then anitalias.

Ty Hockett Said:
"But, Apple provided a TrueType version of Geneva and Monaco as early as System 7 in 1992 (read: built with vectors, scalable to any resolution, and ready to antialias whenever). All this business about how Geneva and Monaco weren't meant to be anti-aliased just isn't true."

the reason for the truetype version of geneva and monoco was for print purposes ONLY, not screen display purposes.

if anyone would like me to go further into extreme detail as to why monoco, geneva, and other bitmap fonts should not be antialiased, i can.

Dave-

Thanks for the info. That's actually pretty interesting, and makes sense of the situation. It's nice to know people are putting this sort of thought into a product, much less bothering to explain and justify things to their end users.

Now would you care to help us determine how many angels can fit on the head of a pin? I've also been trying to figure out lately whether or not Adam and Eve had navels.

ill be breief until someone asks for further explanation:

ask any designer about fonts and cities. they will tell you "Never use a font thats named after a city." Why?

Apple cleverly named bitmap fonts after cities. Monoco, Geneva, Chicago, New York etc...

These fonts were designed to be display fonts, meaning for on screen use only. There were drawn pixel by pixel. Yes, i said pixel, not vector. The screen is resolution dependent, great for display fonts. The printer is resolution independent, great for vector fonts. The only reason anti aliasing came around was to more acurately render vector fonts on screen. There is NO REASON WHATSOEVER to anti-alias display fonts. They were built to be dispayed a certain way. Look at monoco 9 and moncoo 10 as mentioned at the darring firball. The structures are actually different. Each character was redrawn to look the best at each size respectively. if you anit-alias these grid based fonts, they become blurred and un-readable.

vector fonts are different. they should always be anti-aliased. they more closely represent what is being sent to the printer and can reproduce smooth curves and stems of varying widths. vector fonts are created from paths, or mathematical equations to draw the font. that is why the look great at any size.

so, the lesson is. if the font was originally a display font, leave it aliased. if it is a truetype, type 1 or other font, anti-alias it.

ever seen those pixel fonts? now do you know why they tell you to use a specific size and turn off anti-aliasing in photoshop when you use them? cause they were designed to be used a that point size and with anti aliasing off. they are grid based fonts. just like monoco, geneva, chicago, and new york.

ugh...

"at the time Geneva and Monaco were designed anti-aliasing was not an option on the screen"

Right. So it seems incorrect to say they were designed to not be anti-aliased.

bg, I'd like to hear even a superficial reason why they shouldn't be anti-aliased.

PB: ok, ill try my best to explain this:

take for instance the font garamond. garamond was created by, guess who? claude garamond way way way way way back in the day. im talking on the printing press. lead and wood blocks of characters lined up and slaped with ink. then applied to a piece of paper kinda press...

got that?

now take geneva. who created geneva? i dont know but i sure as hell can say that it has never seen a wood or lead block.

why you ask, does this matter...

the first type of computer fonts were bitmap fonts. this is the rise of geneva, monoco, new york, and chicago. each font at each size was drawn individaully. so, geneva 10 is physically a different font file from geneva 9. both these fonts, along with any other sizes were stored in what is known as a suitcase.

now, the reason i mentioned garamod becomes aparent. along comes the laserprinter and what is known as postscript. it allows for high resolution font output to a laser printer. garamond was never designed to be displayed on a screen at small sizes. that is why garamond is a vector font. how do we display vector fonts on a screen? with anti-aliasing.

good class...

geneva on the other hand was created on the computer before anti-aliasing was all the big rage. genava, among other bitmap fonts, were designed to display a certain way at certain sizes. Their strokes are measured in WHOLE pixels and should only be dispayed at the appropriate sizes.

now take geneva in safari. it destroys this completely. the geneva strokes are supposed to be 1 pixel wide. safari smushes this all the hell. definately not the way geneva was supposed to be displayed.

so, bitmap fonts were built to be displayed at certain sizes on screen. each size has an accompanying font file. each font file was hand rendered with pixels.

vector fonts were built to be displayed at any arbitrary size, even fractions of a pixel. so a font size of 22.34 is acceptable. this is because the vector artwork of the characters are scaled in accordance to the font size. because of this, vector fonts are anti aliased to to simulate "not on" pixels, and tricking the eye into seeing a higher resolution.

now you may ask why is geneva a truetype font now?

most people using computers are not typographers, and just use any arbitrary font on their computer to print things up. i see this every day and it makes me cringe. here is where the problem lies. have you ever printed an image from the web to your inkjet or laser printer and it looked like crap. the reason is that the source image is 72 dpi, aka screen rez, and the printer rez is MUCH MUCH higher. the 72 dpi image is being upscaled to say 300 dpi, or even 600 dpi, and on some high end printer, 1200-2400 dpi. well, the same thing happens when you print geneva to a laserprinter. the 72 dpi screen version is being upscaled to 300 dpi, the pixels become larger and the font looks just plain ugly. so, apple was smart, they started including vector formats of all their fonts. so, on screen you have 10 pt geneva. what is being displayed is the bitmap version. when you print, it is swapped for the vector version, and properly upscaled to 300dpi, or whatever your printer is. now the font is nice and smooth.

get it? hope so...

"Are there any plans to support other bits of CSS3 as they develop?"

CSS3 isn't even nearly done. Implementing a wide range of CSS3 properties for public usage is problematic, because CSS3 properties could still be changed to behave differently.

Also, with using the rgba() range, you'll effectively lose ability to have your page viewed properly by 99% of the people.

When all you’re programming is a style system, does every bug start looking like a missing CSS feature?

It seems to me that a “font-smooth” property would fall into the same category as BLINK and MARQUEE: all other things being equal, a browser which didn’t implement it would be more usable than a browser which did. I wish I could say I was surprised at the W3C coming up with such garbage.

implementing the font-smooth property would be huge. HUGE.

STOP LOOK & LISTEN
I have a seiing disability and turn off anti aliasing for fonts under 12 point. Every other app, seems to obey this except safari. I hate fonts looking all smudgy at this resolution, it confuses my brain.
Please follow the system preference setting, safari is great but for some of us with visual disabilities, anti-aliasing is another layer of complexity for our brains to deal with.

I thankyou

dids

I won't talk about what the default should be, but I love the idea to support that.

Because then we can all create user stylesheets if we want and always make 'pre' not anti-aliased, or force anti-aliasing for everything, etc. Sounds very cool. Man I love user stylesheets :)

"Now would you care to help us determine how many angels can fit on the head of a pin?"

I believe Dogbert answered this. IIRC, he said 6.

Although (as Soren Kuklau points out) the CSS3 spec is not finished, Dave Hyatt's solution of making this behavior controlled through CSS should make everyone happy. Remember that Safari uses a default CSS document to style pages. For example: if you, the user, want fixed-width fonts below 12px to appear unaliased, you could set that. Or all fonts. Or whatever.

Admittedly, breaking into the default CSS file is a little extra trouble, but it's nice knowing the functionality would be there.

No, Adam, it would not make everyone happy. The only people it would make happy would be the ~1 percent of geeks who had the knowledge and inclination to spend twenty minutes with a text editor, so they could construct a user style sheet with !important rules to force Safari to do what, in System Preferences, they’d TOLD IT TO DO ALREADY.

“Oh!”, you might say. “But Safari could have a GUI for it!”. Something like this, perhaps?

Obey my anti-aliasing settings from System Preferences:
(*) sometimes
( ) all the time

I mean, really. The idea of having a CSS property for font smoothing is utterly absurd. It's like having a CSS property for screen resolution, or color depth.

@bgmccollum

I got what you are trying to say, but that's not the whole point. If Geneva 9 was _meant_ being a different font from Geneva 10, then it should stay that way even when you print it at 1000000 dpi. But I guess you would like it to use the truetype-version of Geneva for printing. Now, if you want WYSIWYG, you will get the best approximation with AA. On very low-Res Monochrome (that is 1-bit/pixel) displays, the bitmapped fonts were probably the way to go, but it is indeed not sure today in the face of WYSIWYG. You don't even get the font metrics quite right when relying on the bittmapped version, because the letters need to be positioned at full pixel positions. IMHO there are two reasons why you would not want AA:
1) the algorithms aren't good enough. (e.g. fonts with thin lines don't get enough contrast, ?)
2) while it looks nice, it sucks up too much CPU to be worth the trouble.
If I understood Dave correctly, 2 is not really valid for Safari as it would teke Safari more CPU-Power to actually honor the user settings.
1) is in the hands of OS X, which already does a quite good job (I even prefer OS X AA to Acrobat's Cooltype, but your milage may vary). However it might be reasonable to have a more customisable setting, or an algorithm that works like iTunes SoundCheck increasing the contrast of fonts at small sizes, so they actually contain black pixels (when displaying black on white. Perhaps Dave Hyatt can forward that to Apple to make it into Panther ;-)

While I am at requests, I'd really like a hide/show toolbar button that works like it does in iCab (or OmniWeb for that matter) and better offline browsing (again, iCab is pretty cool here).

Regards,
ralf "iSee" welter

Oh, I forgot to mention, OmniGraffle also _always_ uses AA.

This was asked earlier here

iSee

thanks for the reply. I do enjoy discussions. I am a graphic designer and know fonts in and out. and after rereading what I posted, I think I strayed from the point I was trying to illustrate.

you are correct about about the geneva 9 and 10 versions (I meant monaco btw). the only reason there is a truetype version of monaco and geneva is because, as I stated, people would pick any old font and use it for printing and wonder why it looks goofy at certain off sizes, like geneva 13. there is no geneva 13 font, so it would up or down scale the nearest size available, like geneva 12. the problem with this is, you are physically changing the size of the pixels at the printer level. the font just doesn’t look right cause you are using geneva 12 upscaled to 13pt font size. nowadays, we have truetype. so if you pick geneva and set it to say 37pt, it mathematically scales the font using the vector shape of the characters, which translates perfectly to a postscript printer.

here is the thing I was trying to illustrate.

garamond is an old world font. it is very complex in its curves etc. it is pre-computer, pre-true-type and pre-anti-aliasing, this font would be hard to display at small sizes with solid on/off pixels. ok, I have defined that.

geneva monico etc fonts are "newer" typefaces, meaning they were born on the computer in an era of pre-true-type and pre-anti-aliasing. the designer of the font created each character through drawing with solid on or off pixels. the reason the fonts work so well aliased is because they were designed in an era before anti-aliasing and to be legible at small sizes on screen.

now, I wouldn't say these bitmap fonts are the most beautiful thing in the world. most are ugly. but they serve a purpose. to display type at small point sizes and still be legible on screen. you have to remember, these are screen fonts. they were never meant to be printed. they are used in programs to display text.

moving along...a little MORE font history...

here comes postscript and vector fonts. again, this is still before antialiasing. the way it used to work, and still does in os 9 if you don’t have ATM installed, is this. higher quality font come with several files attached to the suitcase. there are the screen fonts at various standard sizes that are bitmap, and then there is the printer font, which is vector. say you open up (back in the day) aldus pagemaker. you lay down a block of text, choose times, and type some text. lets say you choose 12pt times. what you see on screen is the bitmap version of 12pt times. if you look in the times suitcase, there is a file called times 12pt which is what is being used on screen. if you used you changed the font size to say 14pt, the screen would physically switch fonts to times 14pt. now when you go to print to a laser printer, the bitmap version of times isnt used, the printer file times is used, which is vector, and the printer correctly renders times with all it smooth curves and glory. remember back in the day you only had a few choices for font sizes? that is because particular fonts were only made with certain sizes mind. times had 8 9 10 12 14 18 and 24. so, in the suitcase you would have a times file for each size, in addition to a vector file for the printer. this poses a problem. while you may be able to stretch times 24pt to say, 72pt, it was pixelated really bad on screen. it still printed fine on a postscript printer, but on screen, times 72 just looked but ugly. fine for most people, not fine for designers.

so evolution occours....truetype, t1 and other various vector fonts for screen use are developed. these fonts are essntually the same as the printer fonts, but they are able to display on screen. we are still pre anti-aliasing on screen. here is the problem though. while these fonts lets you display a typeface at any given size, like 27pts, they are still being converted to a bitmap based grid of on and off pixels. this works great for larger point sizes like 28pt and up. but when you scale a vector font down to say 9 and 10pt, its hard to accurately represent characters at such a small size cause of the nature of curves vs. pixels. the computer just does the math and spits pixels out. take a look a serif font at 144pt. see how the curves are subtle and sweeping? well, when you scale it down, the computer can get confused and push pixels out of whack in the vector to pixel conversion. essentially, a T had a vertical stroke, and horz stroke, and some serifs on the ends. the bitmap version was designed to work at certain sizes and represent this accurately at small sizes. you cant trust the computer to display the vector version at small sizes, so the hand drawn pixel bitmap version are swapped out and used at small sizes. keeps it ledgible on screen. remember, this is all on screen. it still uses the vector version when you print. along this time classic fonts like garmond and caslon were being dug up from old samples, and recreated in vector format for print use. garamond has never need a bitmap version in its life. trying to recreate it at small sizes with just on and off pixel is just down right impossible. it would look like times or something, which is butt ugly. so, displaying garamond on screen would only look good at larger pt sizes.

the advent of anti-aliasing comes. contrary to what most people believe, the purpose of anti-aliasing fonts on screen is not to make it easier on the eyes to read. small fonts are easier to read when they are high contrast. pure black and white is the most legible combination and why mono, while not the nicest looking font, at 9 pt is highly legible. it serves a purpose, just as a toilet does. the screen as we know is pixel based. vector fonts do not adhere to this display type. anti aliasing simulates what I like to call off base pixels. put a 50% grey pixel next to a black pixel and it looks like 1.5 pixels wide. now we know this is impossible to have 1.5 pixel widths. since curves don’t fall on exact pixels, varying levels of grey are used to simulate off base pixels creating a smoother on screen display. the original purpose of antialiasing was to increase the resolution and clarity of complex vector fonts on screen. anti-aliasing allows us to even more closely represent the smooth curves and shapes in truetype and t1 fonts on screen FOR DESIGNERS (me) and to more accurately display small pt size vector fonts. while 9pt garamond antialiased is not as perfect as its printed counterpart, its servers it purpose to simulate it as close as possible on screen. in OS 9, to enable antaliasing, designers used ATM. vector screen fonts are antialiased on screen, while bitmap old school fonts are not, geneva and monoco being 2 of these. the reason geneva and monoco are not antialiased by ATM is because they are not vector and were never designed to be antialiased. if your not going to use geneva to print, why make a vector version, and why anti alias it....

this is where the trouble starts. geneva and other bitmap fonts were altered. since people were using these fonts to print with, for which they were never designed to be used for, vector versions started to show up ALONG SIDE the bitmap version. now, most people wouldn’t know the difference, but it will create a problem in the future. so, you have a vector version of geneva now, and a bitmap version of geneva. lets say you didn’t have ATM or some other antialiasing extension. you select geneva, you set it to 17pt, type something, and the screen vector version is used. the fonts scales semi well on screen. you print it. well, instead of upscaling to 17pt, the printer used the vector version and everything is just dandy. all is good. so you think. Now, say you have ATM installed, which most average joes don’t have or don’t even know what it is. I pick geneva and set it to 17pt. the vector screen version is used, and it is rendered in its anti-aliased version. remember, geneva is not a font you generally print with. now, I switch to say 10pt. well, ATM is smart and see a bitmap version of geneva 10, which it knows is clearer than the vector version at 10pt and displays it without antialiasing, as it should. clarity is the key when viewing on screen.

so, im happy, your happy, we are all in our os 9 happy days. then all hell breaks loose...

here comes OS X...this is a multi rooted problem that comes from several different angles that has created a really bad situation. OS X is not the problem, but rather, the way in which the problem reveals itself.

Part 1 of the problem: I blame this on stupid people not knowing about fonts in general. Trying to use bitmap fonts at sizes they were never meant to be used at, and using these fonts for printing. What has happened is there are now vector versions of classic bitmap fonts to appease these people. They see it as evolution of computers, font people see it as de-evolution of a font that is a tool.

Part 2 of the problem: Again, I blame this on stupid people. OS X gives anti-aliasing to the masses. While this is a plus, and I do enjoy it, it creates a problem. Everything in OS X is nice and smooth. From the fonts to the icons. People see anti-aliasing as being cool. It is cool, when done correctly and when appropriate. So, you have people that see geneva 10pt in safari being anti-aliased and think it looks great (Sorry Hyatt, you are wrong. You obviously know nothing about fonts if you think geneva should be aliased. Geneva is a screen font that predates anti-aliasing and is displayed correctly aliased). They have hyped themselves all to hell and are stuck on this whole "anti-alias everything" kick when they themselves know absolutely NOTHING about fonts. Its like all those rice boys that think their front wheel drive car will go faster and have better traction because of the huge spoiler on the back. Wrong tool for the situation at hand.

Part 3 of the problem: The web standard is now 96dpi and most browsers support this. Fonts are based on the scale of 72dpi. 72dpi = 1 inch. So, we have a conflict of scale now.

Part 4 of the problem: The correct font display method uses a true type version if the bitmap version is not available at a certain point size. this is the intended method of operation, as bitmaps at certain sizes are more legible then their vector counterparts at the same size. From what I gather, CoreGraphics and QuickDraw in OS X are somewhat erratic in how they displays fonts. I believe this partially ties into problem 1, and certain programmers either bypass the bitmap fonts when available, or the calls bypass them. This is illustrated below.

I have created a test html file with styles defining geneva 8pt - 12pt and monaco 8pt - 12pt.

I checked this file in 5 different browsers to see which sizes of each font are anti-aliased. This has also brought to my attention a problem with font sizes as well.

I also checked these fonts in text edit for reference.

Here are the results:

IE: All fonts are anti-aliased
Netscape 7: Geneva & Monaco 8pt Aliased, All others anti-aliased
Mozilla: Geneva & Monaco 8pt & 9pt Aliased, All others anti-aliased
Camino: Geneva & Monaco 8pt Aliased, All others anti-aliased
Safari: All fonts are anti-aliased

Text Edit: Geneva and Monaco 8pt Aliased, Monaco 9pt and 10pt aliased. All others anti-aliased.

There seems to be a lot of problems throughout the systems with fonts. The display errors with all the browsers seems to be because of problem 3.

8pt geneva and monaco should be anti-aliased.
9pt geneva and monaco should be aliased.
10pt geneva and monaco should be aliased.
11pt geneva and monaco should be anti-aliased.
12pt geneva and monaco should be aliased.

none of the browsers display this correctly.

Mozilla seems to be 1pt size small in its font rendering. 8pt geneva is actually 9pt geneva. 10pt monaco is actually 9pt monaco etc...

Netscape, Camino and Safari seem to be 2pt sizes off. 8pt Geneva is actually 10pt geneva etc...

IE is I believe 3 point sizes off.

The problem gets worse as the type gets larger. It seems that each subsequent point size its actually getting larger exponentially. If monaco and geneva 12pt were actually that big, id type my thesis papers in them all the time.

Now take a look at text edit. The sizes are correct, but I am still puzzled. Geneva 8 should be antialiased. Geneva 9-10 should be aliased. monaco 8 should be antialiased. MONACO 9-10 ARE ALIASED!!! What is going on here.

Obviously there are serious problems in the font world in OSX. Font sizes are not a relative scale. They mean something.

Can someone care to explain why this is happening?

In the end, I think the solution could be simple.

Have a system wide option that has 4 options.

1. Anti-alias all fonts.
2. Anti-alias all fonts except those with bitmap version for certain sizes.
3. Anti-alias all fonts except those that are under a said point size.
4. Work like ATM, give me platinum back, give me pop up windows back, give me list view in dialogs back, give me system wide labels back, give me my apple menu back, remove the dock, remove all drop shadow, and remove column view.

option 4 would make apple a hefty sum of money cause all the designers still using os 9 wouldnt have a reason not to upgrade to OS X. funny, but true.

BGMcCollum:

Just I thought these comments were beginning to enlighten those who may not have the same knowledge of screen based typography technoliges as the average designer, in you wade with your protracted, wordy, incorrect, badly written tract. The car comparison has been done. Your tests are way off the mark. Ever heard of QuarkXpress as reason not to upgrade? Don't call people stupid. You twat.

And before you say it, no, I can't spell very well either.

cheers

when i say stupid, i mean people that dont know the difference. im sure most of them are quite capable souls.

long night explanations never go quite right.

bgmccollum,

I did understand what your were trying to say, but frankly I disagree.
One point that explains, why font sizes seem to be off it that browsers finally have realized the increased resolution of screens, Sadly Mac OS X in general doesn't.
Bitmap fonts are not created at pt sizes but at pixel sizes, which happened to be the same when they were created.
pt is simply a measure for length, namely 1/72 part of an inch. (By international standards 1pt is approx. .353 mm) So Geneva 12 (bitmapped version) is a bitmap image of all characters 12 pixels high. If your screen has a resolution of 96 dpi, this font will be displayed at 9pt. So a browser will need a 16 pixel bitmap image in order to display the font at 12pt. Well my display has a resolution of 91 dpi so my display should (according to you) use the bitmapped representation for text of the sizes 6.32967, 7.12088, 9.49451, 11.0769, 14.2418, and 18.989 if they were available at 8, 9, 12, 14, 18 and 24 pixels. Sadly I don't have a test case for that, and some simple rounding error would ruin it all.

Now that would be if I would agree with your point, which I don't. You have claimed bitmapped fonts would be more legible because they have higher contrast. Do you know about any survey on that, comparing it with the antialiased version taking into account different anti-aliasing methods?

I suspect our vision is more likely to be distracted by seing individual pixels than by a good approximation of a shape using gray levels, but I may be wrong. However, you may be wrong, too. Unless one of us can prove it, we don't know. So it would be nice not to regard other people as silly, just because they do not share your opinion.

There is, however a little experiment you can do, to find out which is more legible. Open Terminal, type "pico" (without the quotes) return and paste some text. Now go to the menu "Terminal->Window Settings?" (the third entry). Choose "Monitor" on the popup and set the font size to 6, but stick with a monotype font. Toggle the "smooth text" box, and check which version is more legible.

What I was trying to say in my last post, is that Monaco 9, Monaco 12, and Monaco Truetype are actually three different fonts that share the same name. Your claim now was, Monaco Truetype shouldn't be used because it was designed after a bitmap image. My earlier point was if the design of Monaco 9 was _meant_ as a bitmap font that it should be printed in all its goody jagginess.
What I don't get is why you think its so smart to actually use different fonts at different sizes, because that is wehat you suggest. I happen to like the font Monaco Truetype. and so I use it. Perhaps Apple should rename fonts to better reflect this, but I am quite happy with just having one font associated with one font name.

Before I add a comment of why AA for all is a good thing(tm) I want to add I do agree are the options you suggest - but perhaps the last one should also include a crash rate-slider that simulates the system going down whenever an app violates memory protection. This is absolutely necessary for the true Mac OS 9 look & feel.

Now on to why Always AA is cool for everyone:
When you write a text in Pagemaker or Word without proper AA, you sometimes can't be quite sure if there is a space after that comma, or if there is a double space between these words, because bitmapped fonts cannot match the exact metrics as each character needs to be positioned on a full pixel. This is gone for good and this really saves most users lots of time.

Regards,
iSee

MPT--
I suspect the 1% of users who care enough about this issue to want to change it has a lot of overlap with the 1% of users who would be willing to break into their default CSS file. 20 minutes? Probably not.

And hey, if CSS3 offers the control, why not exploit it? Complaining that CSS3 is overweening is pretty far off-topic. CSS3, in fact, does have controls for dealing with different bit depths and display sizes.

Congratulations to anyone still reading, perhaps a hardy soul like yourself can answer me a question:

What will implementing the anti-aliasing controls in CSS3 do to rendering speed if a simple pixel size limit is left out for reasons of efficiency?

Or is this merely the programmer's natural fear of calling a bug a bug.

Stop calling Geneva a "newer" typeface "born on the computer in an era of pre-true-type and pre-anti-aliasing."

Geneva is Apple's license free copy of Helvetica, and it was designed before anyone knew what a computer was.

Adam, no-one (that’s zero percent) should *have* to care about why Safari isn’t obeying their System Preferences. It should Just Work. (You may recognize that phrase.) As for the 20 minutes, that includes the time taken to search Google for the explanation of the bug and the instructions for the workaround.

Talk of “exploiting” font-smooth makes no sense, since implementing it would make Safari less usable, not more. If a browser can be more usable by not implementing a specification than by implementing it (without harming other parties), there’s something wrong with the specification.

I hate to agree with mpt, but I do. Letting site authors control anti-aliasing is ridiculous. That choice should be up to users.

(Personally I prefer all fonts anti-aliased, even monospace fonts. That's one reason I use Terminal instead of xterm, even though the latter is way faster.)