• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname


    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

About the ClearType system

Doug Kerr

Well-known member

Most rendering of text on our computers today is done by what are often described as "vector" fonts (that term being somewhat abused there), meaning that the character glyph outlines are described by mathematically-defined curves.

Of course, we normally render these glyph on a pixel-oriented display. Thus a rasterizer (often in the operating system) maps each character onto the pixel grid for rendering.

Of course, this process is not, in general, ideal. When we render a diagonal line in the obvious way onto a discrete pixel grid, the result has "jaggies", and the same is true of the glyph outlines.

There are various measures employed to mitigate the visual effect of this imperfect rendering. Several of them are often described as "antialiasing" measures. How is that?

This phenomenon is ever-so-slightly related to the phenomenon of "aliasing" that occurs when we capture a "continuous" scene with a sensor that consists of a grid of discrete photodetectors. And because of that very distant parallel, the term "antialising" is applied to some of these mitigative measures.
I don't think it is a good term for this matter, but that train is out of the station.​

Gray-scale "antialiasing"

Suppose we have a right-hand vertical boundary of a stroke of the glyph being rendered that should fall (considering the ideal location of the glyph) halfway between the right-hand end of the pixel with horizontal position 125 and the right-hand end of the pixel with horizontal position 126 - we might say at "position 125-1/2".

Suppose that we render that stroke with a black area ending at the right-hand end of the pixel in horizontal location 125, and then paint the adjacent pixels (in horizontal position 126) with a medium gray.

To the viewer's eye (which we assume can't resolve these pixels individually), it looks as if the right-hand edge of the stroke is at the right edge of pixel location "125-1/2". Just what we want.

But in fact, in many situations, the human eye can in fact sort-of resolve the individual pixels on the display. And so the faking of the right-hand edge of the stroke at position "125-1/2" doesn't fully "come off".

The ClearType system

The ClearType system for rendering text character glyphs, devised by Microsoft, is most directly applicable to LED or LCD-based displays, where the individual color dots can be reliably separately addressed. In fact, these can be considered to be (and are spoken of as such in discussions of the ClearType system) "subpixels".

Suppose that the "dot" grid of a certain LCD display is laid out with the three dots for each "pixel" being in horizontal sequence. We see that in this figure:


which shows a 3 × 3 pixel portion of a display grid.

Thus, if we ignore that these "subpixels" are of different hues, we can discretely address horizontal locations (in pixel units) of 125, 125-1/3, 125-2/3, 126, 126-1/3, etc.

Now, if in fact the human eye were not at all sensitive to hue difference, we now have in fact a horizontal resolution when rendering character glyphs of three times the pixel resolution of the display.

And in fact the resolution of the human eye to chromaticity difference is far "coarser" than with regard to luminance differences (a matter we exploit in the "chrominance subsampling" scheme used in the recording of images in JPEG form).

And, simplistically, the ClearType system treats the individual dots as pixels when rendering character glyphs.

Now of course the complete strategy is far more complex that I have described here.

Now a challenge of the system is that the arrangements of the dots differs between different display ("monitor") models. In some (most commonly), the three "dots" for a pixels are disposed in horizontal sequence (as shown above), but in some less-common cases, they are disposed in vertical sequence. And of course there are three different sequences in which the three kinds of dots can be arranged, and three different possible "starting points" for the sequence. This comes up altogether to 12 possible arrangements (if we ignore some more subtle differences).

How will Windows know which one pertains to our display? It may be that is gets some hints over its dialog with the display, or from data Windows already has about the display model (whose "name" is known to Windows). I don't know about that.

But in any case, there is an important but obscure "applet" in Windows called the ClearType Tuner. (As to how to access in various flavors of Windows, your best bet is to look it up in the Windows Help facility.)

This applet allows you to optimize the configuration of the ClearType system for the configuration of your display. The user is presented with several screens, each of which has two or six text passages, rendered with different ClearType strategies applied. On each page, the user picks the sample that "looks best" (wow, this is just like getting one's eyes refracted!).

There are some unexpected results of having a non-optimal ClearType configuration in effect. One is that this can cause an aggravation of the phenomenon in which. as we smoothly scroll a page of text, the text will appear to shift color while "moving".

Best regards,