How Windows 3.11 Rendered Fonts With Font Mapper
This article examines the internal font selection and rendering mechanisms of Microsoft Windows 3.11, focusing specifically on the Graphics Device Interface (GDI) Font Mapper. It details how the operating system translated abstract application font requests into concrete screen typography by evaluating logical font descriptions, calculating penalty scores against installed physical fonts, and delivering rasterized glyphs to the display driver.
In Windows 3.11, applications did not directly manipulate physical
font files. Instead, software requested a font by populating a
LOGFONT (logical font) structure via the Graphics Device
Interface (GDI.EXE). This structure contained idealized
attributes including height, width, weight, character set, pitch,
family, and typeface name. Because an exact match was not guaranteed to
exist on every system, Windows relied on an internal subsystem known as
the Font Mapper to bridge the gap between the requested
LOGFONT and the actual physical fonts available in memory
or on disk.
The Font Mapper operated on a deterministic, penalty-based
arbitration algorithm. When an application called
CreateFont or CreateFontIndirect followed by
SelectObject, the Font Mapper iterated through all
registered physical fonts—including bitmapped raster fonts
(.FON), vector fonts, and scalable TrueType fonts
(.TTF). For every candidate font, the mapper initialized a
penalty score of zero and added weighted penalty points for each
attribute that deviated from the requested LOGFONT. The
font with the lowest cumulative penalty score was chosen as the active
font for the device context.
Attributes carried distinct weights during the mapping evaluation:
- Character Set: The highest penalty was assigned to
a character set mismatch. If an application requested
ANSI_CHARSETand a candidate providedSYMBOL_CHARSET, the penalty was insurmountable, ensuring non-readable fonts were rejected. - Pitch and Family: Mismatches between fixed-pitch
and variable-pitch fonts incurred heavy penalties, as did deviations in
font family categories (such as
FF_ROMANversusFF_SWISS). - Face Name: While matching the requested typeface name was preferred, it carried less weight than critical structural parameters like the character set.
- Height and Aspect Ratio: Size discrepancies added variable penalties. If a bitmapped font required vertical or horizontal scaling, penalties scaled relative to the difference in pixels, favoring candidates that matched the target display aspect ratio.
Windows 3.11 balanced performance across both raster and vector technologies. Bitmap fonts contained pre-rendered strikes optimized for specific resolutions (such as VGA at 96 DPI or 8514/A at 120 DPI). If a bitmap font matched the exact pixel height requested, the Font Mapper often favored it over a scalable font to conserve CPU cycles on slower 16-bit 80386 and 80486 processors. Conversely, if no exact bitmap size was found, TrueType fonts were heavily favored because their outline mathematical models allowed continuous scaling without the geometric distortion penalties associated with scaling bitmapped glyphs.
Once the Font Mapper selected the winning physical font, the rendering pipeline proceeded to rasterization. For TrueType fonts, the embedded TrueType rasterizer read the quadratic B-spline outlines, applied hinting instructions to align stems to the pixel grid, and generated a monochrome bitmap for each required character. For native bitmap fonts, GDI extracted the raw pixel array directly from the font resource. Finally, GDI transferred these monochrome bitmaps into the video display memory using the display driver's BitBlt (bit block transfer) routines, outputting the text onto the desktop interface.