Every preparation API takes a font string. The active measurement backend decides how to interpret that string, but the first-party backends share one parser from Pretext.Contracts.
The parser looks for:
pxitalic or obliqueExamples:
"16px Inter"
"700 18px \"IBM Plex Sans\""
"italic 16px Georgia"
"600 15px system-ui"
"16px Menlo, monospace"
| Token | Effect |
|---|---|
bold |
weight 700 |
numeric weight such as 500 or 700 |
mapped to backend-specific weight values |
italic or oblique |
italic slant |
If the primary family is a generic CSS family, the first-party backends map it to a concrete platform fallback:
| Input family | Effective family |
|---|---|
sans-serif, system-ui |
backend-specific sans-serif fallback |
serif |
backend-specific serif fallback |
monospace, ui-monospace |
backend-specific monospace fallback |
If the parser cannot find a valid size, it falls back to 16px with the backend's default sans-serif family.
%, em, rem, and other non-pixel unitsIf a /line-height segment appears after the size, it is ignored by the parser. You still pass line height explicitly to layout methods.
Pretext stores:
When you use one of the first-party backends, widths come from that backend's native or renderer-specific text stack:
Pretext.DirectWrite on WindowsPretext.FreeType on LinuxPretext.CoreText on macOSPretext.SkiaSharp as the portable fallbackBecause line height is caller-supplied, you stay in control of:
font size * constant.