Rasterising text

A font file stores outlines; a screen has pixel cells. The step in between is rasterisation, and it is why the same typeface does not look identical on every machine.

Outlines are not pixels#

Outlines are Bézier curves (see Glyphs and the em box) and have nothing to do with pixels. Rasterising means mapping those curves onto a pixel grid for the current font size, screen DPI and zoom, then deciding how dark each cell should be.

Three quantities that exist only at this stage:

• how big the grid is: 12px body text is a 24×24 device-pixel em on a 2× screen, 12×12 on a 1× screen;
• where an edge falls inside a cell: the same vertical stem lands very differently centred in a pixel or straddling two;
• how much of each cell is covered: this is what antialiasing is about.

Antialiasing: edge cells take partial coverage#

With only "fully on" and "fully off" cells, diagonals and curves become staircases. Antialiasing gives edge cells partial opacity: a cell 62% covered by the outline is painted 62% dark. At normal viewing distance the eye averages that back into a smooth edge.

This is grayscale antialiasing: R, G and B all change together, producing grey.

Subpixels: three per pixel#

An LCD "pixel" is really three subpixels side by side: red, green, blue. They emit independently, so you can light only some of them — the edge lands with one-third of a pixel of precision, effectively tripling horizontal resolution.

ClearType is the Windows implementation (macOS called its own version subpixel antialiasing). The costs:

• it only holds on screens whose subpixel layout is known (RGB or BGR, upright or tilted, differing per panel);
• turn it off, or let the system decide the panel does not match, and it falls back to grayscale;
• edges pick up visible colour fringes — invisible at reading distance, obvious once magnified;
• at any zoom other than 100%, subpixels no longer line up with CSS pixels and Windows often drops back to grayscale.

Grayscale Subpixel (ClearType)

Both images are deliberately kept on white: in the dark theme we do not invert them, because inverting would swap cyan and orange and say the opposite of what the figure is for.

Why it matters less today#

• HiDPI: phones and laptops are commonly 2–3×. One CSS pixel covers 2–3 device pixels, so a single edge cell is already two-thirds smaller and "winning back another third" is worth less;
• macOS dropped subpixel antialiasing in Mojave (10.14) and went back to grayscale — precisely because at high density it stopped paying for itself while the fringes fought the type design;
• Windows keeps ClearType, but it quietly gives up under fractional scaling, tablet mode and some drivers;
• web fonts often ship no hinting instructions at all, so where stems land changes too (see hinting).

So "it looks different on the two platforms" is normal#

Same typeface, same sentence, same size, and the width can differ by a few pixels between Windows, macOS and phones — with line breaks following. The cause is not the font but the steps above: grid size, antialiasing mode, hinting, and the way metrics are rounded.

It is also why design files and implementations "always differ by half a line" at small Chinese sizes.

What a front-end developer can control#

Almost nothing. Here is what the usual "switches" actually do:

What actually helps is the old advice: avoid sizes like 11px that sit on a critical boundary, give figures enough room, and choose a typeface that is designed to be legible when small.

Why this site does not "simulate" ClearType#

Every specimen here is SVG drawn from the font's own outlines. It shows the shape of a glyph, not what some operating system makes of it:

• SVG carries no antialiasing decision and no subpixels; on its way to your screen it gets rasterised again, by your system;
• so the three pixel rows at the top of this page only explain the mechanism, and are deliberately coarse: the point is that the same coverage can be drawn three ways, not that your display does this.

The two bitmaps in the previous section are the one exception, and what separates them from a simulation is provenance: they are output from a real renderer, with the system, mode and size stated, so anyone can reproduce or contradict them.

What we do not do is hand-build a "this is Windows, this is macOS" pair from the mechanism. Such a figure looks more authoritative, but every pixel in it was placed by hand: it presents a precision that does not exist, and readers take it as what their own screen is doing.

Checklist#

• Is this a question about the glyph or about rendering? (outlines vs system settings and zoom)
• How many device pixels does this size get on the target screen?
• Are you looking at a magnified screenshot as if it were the normal experience? (magnification is for explaining)
• Will this text reflow on another platform or zoom level — and whose fault is that?

Further reading#

• Microsoft: ClearType and DirectWrite antialiasing notes
• Apple: the macOS Mojave release note that removed subpixel antialiasing
• This site: Glyphs and the em box, How to read the metrics figure