TrueType Font Rasterization in Windows 3.11

Microsoft Windows 3.11 converted vector TrueType fonts into screen pixels using a specialized rasterization engine integrated into the Graphics Device Interface (GDI). By taking scalable, mathematical outline descriptions stored in .TTF files, interpreting embedded microcode hints to optimize glyph shapes for low-resolution displays, and applying scan-conversion algorithms, Windows generated precise, 1-bit monochrome bitmaps. These resulting pixel maps were cached in system memory and blitted directly to the video display adapter for rendering.

Font File Parsing and Outline Representation

TrueType glyphs are defined mathematically on an abstract Cartesian grid, typically utilizing 2,048 units per em. Unlike PostScript fonts that rely on cubic Bézier curves, TrueType outlines consist of straight line segments and quadratic (second-order) Bézier curves defined by on-curve and off-curve control points.

When an application requested text rendering via GDI functions such as TextOut or ExtTextOut, the GDI passed the request to the Windows TrueType rasterizer engine (TTFINPUT.386 or built into GDI.EXE). The engine accessed the font file to read tables such as 'glyf' (glyph outline data) and 'head' (global font metrics), extracting the geometric vectors for the required characters.

Scaling and Coordinate Transformation

Because the raw outline data existed in an arbitrary vector coordinate space, the rasterizer first scaled the coordinates to match the requested point size and the target output device's physical resolution (measured in dots per inch, or DPI).

Using a linear transformation matrix, the engine multiplied the vector coordinates to convert design grid units into real device coordinates. At this stage, coordinates were maintained in fractional, fixed-point numbers to preserve mathematical precision before mapping to physical hardware pixels.

The TrueType Bytecode Interpreter (Hinting)

At the standard monitor resolutions of the Windows 3.11 era (such as 640×480 or 800×600), direct mathematical scaling caused severe distortion, uneven stem weights, and closed counter spaces (such as the loops in "e" or "a"). To resolve this, TrueType utilized an embedded virtual machine capable of executing bytecodes—commonly referred to as "hints"—stored within the font's 'fpgm', 'prep', and glyph-level programs.

The rasterizer's interpreter executed these instructions to modify the scaled control points:

  • Grid-Fitting: Snapped control points to the nearest physical pixel boundaries.
  • Stem Regularization: Forced vertical and horizontal strokes to uniform pixel widths across all characters.
  • Drop-Out Control: Ensured that thin strokes or diagonal lines did not break across pixel boundaries, preserving visual continuity.

Scan Conversion

Once the glyph points were hinted and aligned to the pixel grid, the engine applied scan-line conversion to turn the vector outline into discrete pixels.

The rasterizer evaluated scan lines across the device grid to calculate intersections with the glyph's vector boundaries:

  1. Intersection Calculation: The engine determined where horizontal scan lines crossed the line segments and quadratic curves.
  2. Filling Rules: Windows applied the non-zero winding number rule (and alternately the even-odd rule) to determine which regions fell inside the glyph boundary. If a pixel center fell inside the enclosed outline, the corresponding bit in memory was marked active.
  3. Drop-out Prevention Rules: If a vector feature was narrower than a single pixel, the scan converter forced the activation of adjacent pixels to avoid disconnected gaps in the rendered character.

Because consumer hardware in the early 1990s lacked the performance for sub-pixel anti-aliasing (such as ClearType) and high-depth framebuffers were uncommon, the output was strictly binary: a 1-bit monochrome bitmap representing black or white pixels.

Caching and GDI Blitting

To minimize CPU overhead on 16-bit and 32-bit hybrid systems, Windows 3.11 did not re-rasterize characters on every render call. After a glyph was rasterized into a 1-bit bitmap, the GDI placed it into a memory-resident glyph cache associated with that specific font face, style, and size.

When rendering strings of text, the GDI fetched the cached bitmaps, aligned them using the character advance widths provided by the font metrics, and performed a BitBlt (Bit Block Transfer) operation directly to the display driver's video memory or memory device context, presenting the final text on the screen.