A modern X11 server for macOS, built in 30 days.

Anti-aliased font rendering, no compromises

Core Text rendering throughout. Monaco for monospaced cells, real proportional fonts for Motif. Reported metrics equal rendered metrics by construction.

Anti-aliased font rendering, no compromises
xterm running top on a Sun Ultra 5, rendered through macXserver. Monaco at integer pointSize, cell sized from the actual font metrics, anti-aliased.

What it does

Every X font request maps to a Core Text font. macXserver builds the response to QueryFont from the resolved Core Text font’s actual metrics, then renders every glyph through CTFontDrawGlyphs at the same pointSize. There is no path that draws a bitmap-style legacy X font. The setting “use anti-aliased fonts” is not a setting; it’s the only mode.

Why it matters

The bar for me on this project was: an xterm rendered by macXserver should sit comfortably next to an iTerm2 window. iTerm2 has set the standard for Mac terminal rendering, and any new Mac-side X server has to clear it. The classic X server approach — ship a bitmap font for the named XLFD cell, render the bitmap with no anti-aliasing — doesn’t clear it. macXserver doesn’t ship bitmap fonts at all; it ships a curated XLFD-to-Core-Text mapping that picks the right Core Text font at the right pointSize for each X font name.

A nice side effect: any cell size, no errors

Classic X servers ship a fixed catalog of pre-rasterized bitmap fonts: 7x14.pcf, 9x15.pcf, and a couple dozen others. If you ask for xterm -fn 8x14 and the server doesn’t have an 8x14.pcf on disk, you get an error and no window.

macXserver doesn’t have a catalog. It has Monaco at every integer pointSize, on demand. So xterm -fn 8x13, 9x14, 10x15, 11x18 — all valid. Pick a reasonable combination and it just works. The server snaps to the integer pointSize that fits the cell you asked for and reports the actual metrics back. Sometimes the cell you get is a pixel different from the cell you asked for (Monaco’s natural aspect ratio at integer pointSize is what it is), but you always get a font and it always renders cleanly. Nothing to install, nothing to enumerate.

Technical detail

The principle is cell follows font, not the other way around — iTerm2’s playbook. When xterm -fn 7x14 asks for a 7×14 cell:

  1. Pick the integer pointSize closest to what fits.
  2. Instantiate Monaco at that pointSize.
  3. Ask Core Text for its actual advance, ascent, descent, lineHeight.
  4. Report Monaco’s actual cell back in QueryFont.

Step 4 is the inversion: the XLFD becomes a hint, not a contract. xterm uses Monaco’s metrics for layout, the metrics get rendered exactly as reported, and there’s no mismatch possible. Integer pointSize is load-bearing — Core Text’s hinter does its best work there.

For Motif and other Xt-based toolkits using proportional fonts, the same principle generalizes through MOTIF_TEXT_QUALITY: every glyph carries a per-character characterWidth, and both the reported width (in QueryFont / QueryTextExtents) and the rendered advance (in PolyText8 / ImageText8) come from the same Core Text source. Same invariant, broader scope.

Curated XLFD-to-Mac-font mappings live in ~/.macxserver-fonts and are user-editable. The Resources editor in the GUI exposes them with column highlights.

  • Day 5 was the resolution of the 3-day xterm text arc — see the ledger.
  • The MOTIF_TEXT_QUALITY invariant landed Day 14.
  • QueryTextExtents accuracy fix landed Day 11 (unblocked Motif menu spacing).