| design | mean segs | min dist | noise .02 | noise .05 | noise .10 | jitter 1px |
|---|---|---|---|---|---|---|
| 1–2 segments, max-min selected | 1.59 | 0.407 | 100.0% | 100.0% | 100.0% | 97.5% |
| 1–3 segments, max-min selected | 1.96 | 0.439 | 100.0% | 100.0% | 100.0% | 98.5% |
| 1–2 segments, randomly selected | 1.85 | 0.112 | 100.0% | 100.0% | 99.8% | 94.7% |
How it was built, not drawn. Every glyph is a polyline on a 3×3 lattice — one stroke, no pen lifts, no immediate reversals, no repeated segment. All 576 such paths with at most two segments were enumerated, rasterised to 16×16, and 27 were selected by greedy max-min diversity: repeatedly take the candidate furthest from everything already chosen. Nothing here was designed by eye.
Frequency drives the assignment. Letter counts came from the corpus, and the 11 single-segment glyphs — a bare straight line, no corner — went to the 11 commonest symbols: space, a, c, e, h, i, n, o, r, s, t. The rarer letters carry the two-segment shapes. Same principle as a variable-length code: spend strokes where they are used least.
Why 1–2 segments and not 1–3. Allowing three segments raises minimum separation from 0.407 to 0.439 and jitter robustness from 97.5% to 98.5%, at the cost of 23% more strokes. The two-segment set is already at ceiling on noise, so the extra complexity buys almost nothing. Selection matters far more than segment budget: randomly choosing 27 two-segment glyphs collapses minimum distance to 0.112, a 3.6× loss, with more strokes than the designed set.
One correction to the premise. An embedder does not read glyphs — it reads token ids, and it would behave identically if the letters were drawn as anything at all. What has to survive here is the recognizer, the step that maps ink to a token. So the chain is glyph → recognizer → token → embedder, and this alphabet is engineered for the first arrow. That arrow is the one that was missing from the pipeline, and it is where a badly designed alphabet would break everything downstream.