As a long time windows user I must also say I much prefer the Mac philosophy of rendering fonts. It took a little while to grow on me but now that it did I can’t go back. Often I look at a web page in Safari and I’m not even sure if I’m looking at HTML text or text in a inlined JPG.
It’s only now that I really appreciate the aesthetic pleasures of good typography.
One poster mentioned that Japanese fonts in Windows are only bitmapped and that was true up to Windows XP. Windows Vista includes a Cleartype-enabled Japanese font called “Meiryo” That being said, despite being a nice improvement over the ubiquitous MS Gothic, it still loses out IMHO to Safari’s Japanese Font rendering, which is simply stunning.
The two technologies ARE ”available in the same OS”. I work in InDesign (creating magazine pages for print) and it, of course, does not at all use Windows’ built-in on-screen type rendering – it has its own engine. The text is not as legible, but the WYSIWYG is better. Which is great, and as it should be.
So for print, all this is a complete non-issue. There is no ”excuse” for Apple’s method; they really go for that look on the screen. It has nothing to do with ”printing from Mac OS X”, that’s a nonsense red herring that can only come from non-professionals.
I cannot stand Windows font rendering. Microsoft renders to the pixel grid. The result is that every diagonal line shows the pixels. There are lots of sharp black and white contrasts in those diagonal lines that don’t belong to the character originally. Especially bad with a large ‘S’. The pixel-grid-based appearance of Windows fonts confuses me. This is also an issue when you read both on-screen and from paper.
Apple renders to an overall grey impression. This approximation is more easy to read. The visual system inside the head can reconstruct the characters from there. This allows also very fine grey approximations with screens with high DPI.
I guess there are people who prefer the Microsoft way of rendering fonts. The visual system of some people might benefit from the sharper contrasts. But really deciding which is better for the reader should be done after several days of using them. Viewing habits are not easy to change in a few minutes. Many people are used to Microsoft’s rendering and Apple’s rendering might look strange for the first hours, but after some time (hours/days) you might or might not like it. But then the decision is not done on viewing habits. Try to use the Apple rendering for some time and then go back to Microsoft’s rendering. You might be surprised.
I’m not a print expert, but I am a programming and language expert. Never have I been the victim of dot vs. dash or some other character at small font 2 hour search problem. First and foremost, the right tool, compiler or lint would flesh that kind of thing out immediately so don’t blame it on the font rendering system. That is the tool user’s problem, or lack of tool using. Second, the argument about reading on screen vs print is total BS. I work on a screen and not once since about 1989 or 1990 have I printed out volumes of code listings to view, total nonsense to argue that is a valid angle on this silly dispute. I want screen display to be easy to read, and I find sizing fonts solves all problems to a reasonable 14 point instead of 10 or 12. Zoom in or out of documents of PDF type and that removes that type of problem too. The iPlone is a good example of what is to come, expect 200-300 dpi sub 5" devices in the next 12-24 months, and in 36-60 you can expect that to ship in all form fractors making grid and pixelated solutions rather meaningless. At that time all design will be embracing verctors and not rasters to describe. Today, this ‘half baked’ OS X solution to rendering works great. If ya don’t like it, turn it off in preferences.
most commonly used fonts on the web have specific hinting and spacings for small pixel sizes intended to increase readability and reduce reading fatigue. You lose the font designers intentions when you start distorting the letters just to flip pixels. Word shape recognition is reduced. etc.
not to mention that the ms way only produces acceptable results on blocky fonts (arial, verdana, tahoma) it is horrible with serifed or accented fonts as well as non western fonts like asian and arabic letterforms.
i could see how one could confuse individual letter clarity preferences with actual readability statistics, like wpm over x/time etc.
i prefer to see the letters as the font designers intended.
Sorry about multiple comments in a row, but check out this comparison of 14 different font rendering variations across 3 platforms: http://artofcode.com/fontfocus/compare.html
“most commonly used fonts on the web have specific hinting and spacings for small pixel sizes intended to increase readability and reduce reading fatigue. You lose the font designers intentions when you start distorting the letters just to flip pixels.”
I’m sorry, but this is a contradiction. Who do you think created and intended the “specific hinting and spacings”? I recently spoke with a renowned font designer, and he complained that Apple ignores the hinting he (and other designers) specifically puts into his fonts. Mind you, I am a proponent of Apple’s font rendering (for the most part), but this plain ignoring of pixel hinting gives Apple a bad name in font designer circles. At least, they could make it an option. I also do not like the way ClearType looks, but something along the line of FontFocus, which you linked to, seems to be a balanced approach, at least for smaller type.
An addition: In an article by John Gruber which was linked to before in the comments on the previous article (http://daringfireball.net/2003/11/panther_text_rendering), it is shown that Apple did change its rasterization technique to align fonts more closely on the pixel grid vertically. The “blurring” problems we are seeing are mostly horizontally between letters. What that means for hinting, I do not know.
It’s rather long but I hope there is some interest in it.
I tried to summarize my experience and observations
concerning the situation with text rasterization in Windows
and Linux. The article also contains demo applications to play
with my method of RGB sub-pixel text rendering. I admit some
statements may sound questionable, so, I appreciate any comments,
criticism, and discussions.
“Not only that, but when you work in small fonts like I do (to maximize screen space) things become pretty much illegible below about 9 pt on OS X because it ends up as a garbled gray mess, but you can go to 7 pt (or sometimes lower) on Windows and still have readable text.”
Apple Menu System Preferences Appearance Turn off smoothing for font sizes [n] and smaller /dumbass
I prefer the rendering on Macs, the spacing between letters on PCs looks too weird for me. Another thing that will affect your preference is the system you use more often. If you typically use a Mac and then look at a PC … yuk and the other way around. In the magnified pics above, you were lucky to get letters that ended up with one pixel between each letter on the PC version. In some fonts on Windows, some letter spacings jump between, let’s say, 2 pixels and 1 pixel. To me that looks horrible.
Disclaimer: I haven’t tried Vista to see if there’s any difference.
The old assumption that displays are 72dpi has been rendered obsolete by advances in display technology. Macs now ship with displays that sport native resolutions of 100dpi or better. Furthermore, the number of pixels per inch will continue to increase dramatically over the next few years. This will make displays crisper and smoother, but it also means that interfaces that are pixel-based will shrink to the point of being unusable. The solution is to remove the 72dpi assumption that has been the norm. In Leopard, the system will be able to draw user interface elements using a scale factor. This will let the user interface maintain the same physical size while gaining resolution and crispness from high dpi displays.
The introduction of resolution independence may mean that there is work that you’ll need to do in order to make your application look as good as possible. For modern Cocoa applications, most of the work will center around raster-based resources. For older applications that use QuickDraw, more work will be required to replace QuickDraw-based calls with Quartz ones."
As he noted, users of Japanese (and probably Chinese and Korean versions) of Windows even in XP do not benefit from ClearType. Font rendering in XP remains for those users just as backwards as it was in Windows 3.1.
I recently remembered this problem existed when I reinstalled Windows XP the other day – most Japanese users are greeted with a UI close to the first screenshot in this page : http://www.geocities.jp/poe99/CAT/XP/page08/index.htm
For some reason I can’t remember – and a MSDN blogger even addressed this at one point, the native Japanese fonts, MS Gothic and MS Mincho, are instructed to ignore ClearType rendering at all cost.
There was a mod at one point listed that more or less required you to decompile the Microsoft-provided fonts and to recompile them without the “Ignore ClearType” flags. Once you have your freshly un-castrated files, you simply replace the files and you’re greeted with a much more pleasant reading experience found in the second screenshot of the LOVELY XP! page linked above.
However, there’s been a new development – with the release of Vista, there’s also a new typeface! A ClearType-enhanced Corbel-alike for Japanese (and possibly other versions too) users called Meiryo.
You can see the differences in the last screenshot of LOVELY XP! The author was able to get his hands on the Meiryo typeface. The implementation is not perfect due to the way Windows handles and replaces fonts on-the-fly. Windows, according to the registry uses FontLink to replace Tahoma with the appropriate font when Tahoma cannot accomodate the character set (ie displaying say, a Japanese word in the middle an English sentance)
It appears that if you simply replace MS UI Gothic with Meiryo, the typeface becomes bolded twice and muddled (last screenshot; left), versus when you simply relink Meiryo with Tahoma in the registry (last screenshot; right). I’ll look into this more when I get home. I still don’t fully understand the process or what causes the difference.
I find that all anti-aliasing is awful, and from what I know, it has become very difficult to disable anti-aliasing on all common operating systems, Windows XP being the last one where it was easy.
Vista doesn’t let you disable AA for all fonts, some remaining blurred. Also some of the fonts it uses by default rasterise very poorly, probably missing hinting.
OS X demands extra TinkerTool hacks, and even after that the fonts are rasterised poorly, probably missing or not using hinting, from what I’ve read. (I haven’t actually used OS X.) Hinting is absolutely necessary for unblurred fonts.
On Linux, the bytecode interpreter needed for hinting is often disabled for patent reasons, and the “autohinter” is joke in case of unblurred fonts, and not that good with blurred ones either. Furthermore, even if the bytecode interpreter is compiled in, it is very difficult to write the hundreds of lines of XML to disable blurring, and allow beautiful old X11 bitmap fonts (that the AA/TTF-fundies distributing the software block in general and some in particular, substituting with worse poorly-rasterising TTF fonts), and so on. (Gnome and KDE let you configure some, but not all aspects for themselves, but not other applications, and if one has to even touch Gnome or KDE, one could just as well use Windows or OS X. Some distributions provide shortcuts to some of these operations, but demand root/superuser access that you might not have, or prefer not to use for such tasks that should be trivial.)
300dpi probably isn’t good enough to not see the pixels–the blur or rainbow colouring in case of anti-aliased fonts, irrespective of method, on the typical flat high contrast background situation necessary for reading comfort (what little can be had on bright computer displays as opposed to non-reflective paper). Maybe 600dpi would be enough. In any case, anti-aliasing has defeated itself at a resolution where the method used – or not used – no longer matters in personal ergonomics. But the trend in computing seems to be that “OS designers know better”, and therefore personal choice is made difficult, and you’re expected to “sacrifice present on the altar of the future”, quoting the original post.
I just tested out the Safari browser on an XP machine. I LOVE the speed of the browser. I sure wish they would fix the fonts because that makes it unusable to me. I opened firefox and Safari side-by-side on my desktop and the difference is amazing. In safari the text is blurry and colorful. I found this page searching for a solution because I really WANT to use Safari. Its great in most other aspects but completely unusable due to the fonts.
I feel I’m pretty impartial here. I have one server running Debian Etch, a desktop running Ubuntu and use XP occasionally at home and daily at work. I’m generally anti-microsoft (and hate IE 7).
I’ve tested this on several quality monitors and its the same on each: undeniably blurry.