What Are They?
Here are two samples of text with and without font smoothing turned on (sample text is in Textile font, size 24):
And here is the (visual) explanation of why the right hand side looks better:
When the outline of a character is scan-converted to a bitmap, the limited resolution of the screen device causes "jaggies" to appear along non-vertical and non-horizontal portions of the contour. By adding levels of gray along oblique or round edges, your eyes get tricked into perceiving smoother contours. To produce the gray-level pixmaps for anti-aliased text, the new TrueType scaler in Mac OS 8.5 still uses the grid-fitted outline for the requested size. But, before passing the outline to the traditional black-white scan converter, it conceptually replaces each pixel by a square of 4x4 sub-pixels, and applies the scan conversion to four-times the original resolution. The count of black dots in the resulting bitmap squares for each pixel (a number between 0 and 16) is then mapped to a gray level encoded in four bits (a value from 0 to 15), which becomes the pixmap's pixel value. QuickDrawText's blitter then looks to it that these gray levels blend nicely from the text's foreground color into the existing background color.
What are the issues?
So far, so good. Unfortunately, this approach comes with some potentially annoying consequences (some of which are alluded to in the "Mac OS 8.5 Read Me" file):
a) Font Smoothing ON implies
Boolean IsAntiAliasedTextEnabled(SInt16* outMinFontSize);
The first function returns a Boolean with the obvious interpretation. If you are interested in the minimum size for which anti-aliasing is enabled, *
outMinFontSize returns this value as set by the user in the Appearance control panel, provided the function value is TRUE; if the function value is FALSE, *
outMinFontSize is undefined. If you do not care about this minimum font size, pass NULL as parameter.
The second function allows to set the state of anti-aliased text; if
inEnable is TRUE, the
inMinFontSize parameter is put in the place where a user-selected minimum font size value would go. Because the rendering quality of anti-aliased text for small point sizes is currently perceived as unsatisfactory, minimum sizes below 12 are not allowed, and are, in fact, replaced by 12. The function always returns
Here is an example of how to use these functions to turn anti-aliased text temporarily OFF (if it's enabled):
//------------------------------------------------- Boolean userWantsSmoothText ; SInt16 previousMinSize; userWantsSmoothText = IsAntiAliasedTextEnabled(&previousMinSize); if (userWantsSmoothText) (void)SetAntiAliasedTextEnabled(false, 0); // second parameter is ignored when first parameter is FALSE // draw text the "jaggy" way, here // and then set it back to what the user wants: if (userWantsSmoothText) (void)SetAntiAliasedTextEnabled(true, previousMinSize); //-------------------------------------------------
One more thing: the symbols
SetAntiAliasedTextEnabled are exported from the
FontManager code fragment in the System, but the
InterfaceLib you are using with your development tools may not yet include them. To make the Linker happy, you may need to create a little "
FontManager" stub library that exports these symbols and contains empty implementations of the functions, until the next revision of the
Clearly, there was no anticipation of anti-aliasing in the original design of QuickDraw. When a bitmap edge gets smoothed by using shades of colors that blend the foreground color into the background color, the fringe of intermediate shades does not participate in the highlighting algorithm. Assume that the foreground color is black, the background white, and the highlight color pretty saturated (like a dark blue or red). With anti-aliased text, there will be a fringe of more or less light-gray pixels around the original black bitmap, to blend the contours into white. When highlighting is applied, the white background pixels are replaced by the relatively dark highlight color, whereas the "fringe" pixels keep their original values. The effect is an ugly sparkling around the contour, which can make the text nearly unreadable in small sizes and certain type faces.
Apple tried hard to find a solution to this problem, but the evidence of the facts won. It is not possible in practice to maintain feature b) above (a requirement for compatibility with existing code), while modifying feature a) such that contours blend correctly into whatever the background pixels are (highlighted or not).
The solution has to come from a different approach to highlighting. Either the highlighted areas are first erased to the desired state (highlighted or not), before the text is drawn into the area, or we provide two different API calls for Highlighting and Unhighlighting and implement them in a way that takes anti-aliased text into account. (See the functions
ATSUUnHighlightText in ATSUnicode.h for an example.)
For the time being, we recommend you use a pastel-like highlight color which minimizes the ugliness, or to turn off anti-aliased text altogether if you are frequently editing text in sizes and type faces that make the defect particularly annoying.
Mac OS 8.5 introduced the feature of anti-aliased text, which provides a substantial esthetic improvement in many text drawing cases, in particular for slanted type faces. However, it became apparent that it may conflict with assumptions made in legacy code, and that it comes with other undesirable side effects. Expect that the future will bring certain improvements.
On the other hand, perhaps we should follow the recommendation "enjoy moderately and wisely" not only for some other good things in life, but also for font smoothing.
Acrobat version of this Note (84K).
Contact ADC | ADC Site Map | ADC Advanced Search
|For information about Apple Products, please visit Apple.com.|
Contact Apple | Privacy Notice
Copyright © 2002 Apple Computer, Inc. All rights reserved.