Why text appears different when drawn with GDIPlus versus GDI

Text layout with GDIPlus is resolution-independent. The effect of this feature becomes apparent when GDIPlus text layout is contrasted with the resolution-dependent GDI text layout.

In grid-fitted rendering (the default), font hinting usually changes the width of glyphs. When a sequence of glyphs all increase significantly in width, GDIPlus may have to tighten up the text to remain resolution-independent. In extreme cases (such as a long run of bold lowercase "l" glyphs in 8-point Microsoft Sans Serif font on a 96 dots-per-inch [dpi] display), the space between some letters can disappear completely.

Forms built with GDIPlus text layout appear the same at all resolutions and when printed.

Resolution-Independent Layout

The DrawString and MeasureString functions in the GDIPlus application programming interface (API) lay out text independent of device resolution; therefore, a paragraph of text takes the same number of lines, no matter which device it is displayed by. There are many other benefits as well, including the following:

• If a field on a form is sized to fit some static text on one developer's computer, it will fit that text on all computers that the application may run on, regardless of screen resolution or accessibility settings.
• When the form is printed, it will lay out the same as it appears on the screen.
• A form recorded in a metafile retains its layout.

Consider the forms designer. A box is defined on the form for some text -- a title, perhaps. You type the title and adjust the box to fit it. Unfortunately, unlike the lines, the text does not scale linearly with resolution, so the box fits correctly only at the resolution that you (the designer) were working in.

For graphical objects, such as lines and pictures, a different device resolution means a different scale factor at display time. A logical line that would be 100 pixels long on a 96-dpi display is drawn 125 pixels long on a 120-dpi display, and 625 pixels long on a 600-dpi printer.

For text, the font height is scaled appropriately for the device resolution: A font that is drawn 20 pixels high on a 96-dpi screen is rendered 25 pixels high on a 125-dpi screen and 125 pixels high on a 600-dpi printer. However, the width of individual glyphs will scale only approximately with the height. The exact width is also dependent on hinting instructions that have been included in the font to adjust the glyph's shape (grid fitting) for legibility.

TrueType Hinting, Grid Fitting, and Their Disproportionate Effect on Glyph Widths

Grid Fitting -- the application of TrueType hints -- is the process of adjusting the position of pixels in a rendered glyph to make the glyph easily legible at screen sizes. Hinting techniques include the alignment of glyph stems on whole pixels and insurance that similar features of a glyph are affected equally. Font designers spend many hours hinting each glyph.

For example, consider the letters "s", "e", "w", and "l" from the Times New Roman font, rendered at 8 points on various resolutions, using GDI's standard grid fitting.

In the following examples, each glyph and its bounding box is drawn at high resolution in gray, and then the actual pixels representing it at a given size and dpi are drawn on top as black circles. 96 dpi is the most widely used display resolution, also known as "small fonts" in the Display Settings dialog box in Control Panel. The 120-dpi case corresponds to the common "large fonts" display setting. 150 dpi is becoming a common portable computer LCD screen resolution, and 600 dpi is a current low-end resolution for a laser printer.

Notice how, at 96 dpi (standard screen resolution), there are very few pixels in an 8-point glyph. The 8-point 96-dpi lowercase "s", for example, has almost none of the character of the glyph that it is intended to portray.



The first figure below each glyph shows the actual resolution of the drawn glyph. The second figure represents the difference between the designed width of the glyph and the actual drawn width as a positive or negative percent. The third figure represents the difference as fractional pixels at the actual display resolution.

In the following example, the leftmost glyph, an 8-point 96-dpi lowercase "e" is about 11 percent, or .61 pixels narrower than its ideal shape after grid fitting.



If there were no grid fitting, we would expect the only difference between the designed and displayed width to reflect the effect of rounding to the nearest pixel. In this case we would never see a width difference of more than one-half of a pixel. At the highest resolution (2400 dpi), this is indeed the case, the biggest difference seen here amounting to 0.37 pixels.

However, at lower resolutions, the effect of grid fitting can exceed or swamp simple rounding. Consider the letter "w", on which the effect of hinting is particularly extreme. On the other hand, the letter "l" is both narrow and composed of only one stem, and therefore shows mild effects of hinting.

How GDIPlus Compensates for Grid Fitting

When Grid Fitting Generates Glyphs That Are Narrower Than Designed

The worst case in the preceding examples is the 96-dpi lowercase "w". The "w" is a particularly difficult glyph to hint well: The stems must appear symmetrical, evenly spaced, and of equal thickness. Careful hinting results in a good appearance, but the hinted glyph is over 2 pixels narrower than its design width. A string composed only of the 8-point 96 dpi "w" will be 23 percent shorter when grid fitted.

When GDIPlus displays a line of grid fitted glyphs that are shorter than their design width, it follows these general rules:

• The line is allowed to contract by up to the width of the em square without any change of glyph spacing. (See the "References" section of this article for more information about the em square and its use as a unit of typographic measure.)
• Remaining contraction is made up when you increase the width of any spaces between words, to a maximum of doubling.
• Remaining contraction is made up by introducing blank pixels between glyphs.

The following example shows how GDI and GDIPlus display the string "wwwww wwwww wwwww wwwww wwwww" in 8-point Times New Roman font at 96 dpi with grid fitting.


This example shows how GDIPlus uses design widths to lay out the string, and so measures the whole string longer than GDI does. GDIPlus allows the string to stop short of the far end by 1 em and places the remaining expansion in the spaces.

The following example shows the same strings with the spaces removed. GDIPlus cannot use the spaces to compensate for the contractions caused by grid fitting and instead inserts an extra pixel between some of the glyphs.

When Grid Fitting Generates Glyphs That Are Wider Than Designed

Now consider the following examples, which use the Microsoft Sans Serif Bold font at a size of 8 points. Microsoft Sans Serif is the default user-interface font for Microsoft Windows 2000-and-later operating systems.






In this case, most of the glyphs are wider than they were designed when drawn at 96 and 120 dpi. Although many are not much larger, there are some particularly difficult cases.

Consider a string at 96 dpi composed of only a lowercase "l". Although each "l" is only .16 pixels wider than its design width, a run of just 7 characters is enough to exceed the design width of the run by a whole pixel. In this case, you must compress the string by 1 pixel. Unfortunately, the shape of the lower case "l" behaves very poorly when a pair of them is overlapped by 1 pixel: Because there is only 1 blank pixel column, the overlapping process causes the adjacent glyphs to form a solid.

The following example shows a run of 9 lowercase "l" characters displayed by GDI and by GDIPlus:


Notice how in GDIPlus the last two "l"s appear to touch.

You can also see in this example that GDIPlus adds a small amount (1/6 em) to each end of every string displayed. This 1/6 em allows for glyphs with overhanging ends and also gives GDIPlus a small amount of leeway to help with grid-fitting expansion.

One example of a glyph with overhangs is the italic f from the Times New Roman font. The topmost trailing feature of the glyph overhangs the glyph to the right (the glyph's trailing neighbor), while the leading bottom-most feature extends under the preceding neighbor. Because the overhang and underhang intrude into the space of a neighboring glyph, they do not contribute to the f glyph width. Therefore, the overhang renders beyond the width of the string when the character is located at the end of a string. The 1/6 em provides the additional space into which the overhangs can be rendered.

How to Display Adjacent Text

Perhaps you want to display two strings side by side so that they appear as one string. You might want do this if you are writing an editor, or are displaying text with a formatting change inside the paragraph.

WARNING: Lines built of text with multiple DrawString calls are inherently unable to display general International text. In particular, in Arabic, Hebrew, Farsi, and other right-to-left languages, strings advance generally from right to left, with localized order reversal around numbers and around western phrases. DrawString handles this scenario within one output, using bi-directional behavior defined by Unicode. The rules are complex. For more information, refer to "The Unicode Standard Version 3.0," section 3.12.

The default action of DrawString works against you when you display adjacent runs: First, the default StringFormat object adds an extra 1/6 em at each end of each output; second, when grid fitted widths are less than designed, the rendered string is allowed to contract from its measured size by up to an em.

To avoid these problems, do the following:

• Always pass MeasureString and DrawString a StringFormat object based on the typographic StringFormat (GenericTypographic).
  
  -and-
  
  
• Set TextRenderingHint graphics to TextRenderingHintAntiAlias.

These measures disable the extra 1/6 em added at the run ends, avoid the problems of grid fitting by using anti-aliasing and sub-pixel glyph positioning, and result in perfectly scalable text. The result may be a little gray at smaller sizes. To compensate for this, use the SetTextContrast function to darken the anti-alias text.

The following tables compare GDI, GDIPlus GridFitted, and GDIPlus anti-alias text for the preceding examples.

Formatting with Spaces
Worst Narrow Case
Worst Wide Case
Although anti-alias text can look a little gray at very small sizes (this is 8-point), it shows the shape of the glyphs far more accurately than grid fitted text, and does not suffer from the glyph position adjustment (described earlier) for grid fitting.

When to Use GDIPlus

A DrawString call is intended to display whole lines or paragraphs in a single format. It is great for user interfaces such as forms, where the scalability guarantees a layout independent of display resolution. When you work with multiformat text by displaying individual runs, do either of the following:

• Use DrawString with the typographic string format and TextRenderingHintAntiAlias, as discussed earlier in this article.
  
  -or-
  
  
• Use GDI's ExtTextOut or UniScribe (the Unicode Script Processor).

Glossary

Additional Reading

For more information about the Unicode standard, refer to the following: The Unicode Consortium. The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5.

On the Internet: For more information about the OpenType specification, browse to the following Microsoft Web site: Also available on the Microsoft Developer Network Library CD-ROM under Specifications.

For more information about the em square, hinting, and the process of grid fitting, see the "TrueType Fundamentals" appendix in the OpenType specification above, or browse to the following Microsoft Web site: For an introduction to UniScribe, the Unicode Script Processor, see the following: