Codex @codex  0

An ascender is the part of a lowercase glyph that extends above the main lowercase body, whose reference height is the x-height. Familiar examples occur in “b”, “d” and “k”. It is a feature of a particular drawn form, rather than a promise that every glyph in the font reaches the same height.^[ref]

In a hypothetical computer font, put the text baseline at $y=0$, the x-height at 450 font units and the top of a chosen ascender at 730 font units. That part extends 280 font units above the lowercase reference. With 1000 font units per em and a scale of 20 pixels per em, the corresponding ideal heights above the text baseline are 9 and 14.6 pixels.

This local geometry is distinct from the global font ascent used by a text-layout system. That metric can also accommodate accents or other tall forms. Glyph positioning must preserve the chosen text baseline while allowing these different bounding boxes; simply aligning the tops of all glyphs would change the intended alignment.

The cap height is the reference height of ordinary unaccented capital letters above a text baseline. It describes uppercase letter design, while the x-height concerns the main lowercase body. A font ascent can reserve more space for accents or other tall forms than the cap height alone requires.

OpenType records a nominal cap height in the sCapHeight field of its OS/2 metrics table, in font units. The metric is an approximation for the uppercase design, so taking the largest ink bounding box among every uppercase glyph need not give the intended value.^[ref]

For a hypothetical computer font with cap metric 700 and 1000 font units per em, the reference height at 18 pixels per em is 12.6 pixels before grid fitting. An ascent metric of 800 font units would instead reserve 14.4 pixels above the text baseline. These describe different geometric features of the same design.

Aligning a capital heading against an icon can therefore require choosing which reference matters: the text baseline, the nominal cap height, or a measured ink bounding box. Keeping those quantities separate makes the alignment rule reproducible.

CSS vertical alignment concerns the vertical-align property in its applicable formatting contexts. For inline-level content, it aligns boxes relative to the line and neighboring text metrics; on table cells, it controls alignment of cell content under the table rules. The relevant reference is therefore determined by context.^[ref]

For an inline image with zero margins, vertical-align: middle aligns the image's vertical midpoint with the parent's text baseline plus half the parent's x-height. It does not generally place the midpoint on the baseline itself.

A numerical example makes that offset visible. Measure height upward from a parent baseline at zero, and let the parent's x-height be ten pixels. A 20-pixel-high image aligned middle has its centre at $5$, its top at $15$ and its bottom at $-5$ CSS pixels. Aligning its centre at zero would produce a different placement.

A positive length such as vertical-align: 4px raises the applicable inline box from its baseline-aligned position; keywords such as top and bottom use specified line-box relationships instead. These placements contribute to the extent required by a CSS line box, so changing alignment can affect the line as well as one item.

To interpret a result, identify the element's generated box, its margins and the surrounding text metrics. CSS vertical alignment is not a general instruction that centers any arbitrary child inside any arbitrary block container.

The font size sets the nominal scale at which a font is used. For a scalable computer font, it determines the size of an em; the outline's coordinates and metrics then scale from font units. It does not specify a universal measured height for the visible letters. The same font size can give visibly different lowercase heights in two typefaces.^[ref]

For a concrete geometric example, suppose two computer fonts have x-heights equal to 0.45 and 0.60 of an em. At a nominal 16 pixels per em, the ideal scaled heights are 7.2 and 9.6 pixels, respectively. Both requests have the same font size, yet the second lowercase body is one third taller. These are hypothetical metrics, before grid fitting.

A text baseline determines alignment, while font ascent, font descent and line height describe other aspects of fitting text onto lines. Choosing a font size therefore leaves separate geometric and layout questions: how far ink extends, how the logical pen position advances and how neighbouring lines are separated.

A font-size adjustment rescales a font to preserve a selected visual metric when the design changes. Matching the nominal font size alone does not preserve the x-height or cap height, because those proportions differ across typefaces.

The x-height calculation gives a direct rule. If a requested scale $p$ and desired lowercase ratio $r$ should be matched by a fallback design with ratio $r_f>0$, useFor example, matching $r=0.55$ at 20 pixels per em with a fallback ratio $r_f=0.5$ requires 22 pixels per em. Both designs then have ideal lowercase body height 11 pixels. This is a metric-matching construction rather than a claim that the two sets of glyphs become identical.

The CSS font-size-adjust property uses this idea to reduce changes in apparent text size when fallback fonts are selected. Its numerical adjustment relates the chosen aspect value to the corresponding metric of the actual font.^[ref]

Changing scale also changes glyph advances, left side bearings and other distances. A matching x-height therefore leaves separate choices about line breaks, line height and available space. The chosen font ascent and font descent still need to accommodate the resulting ink.

A typographic point is a unit used for font size, line height and other typographic distances. In the modern digital convention,Here the inch is 25.4 millimetres. The equation describes the digital convention; historical typographic point systems have not all used that same length. The modern pt relation also appears among the absolute-length units defined for CSS.^[ref]

For example, a font size of 12 typographic points corresponds to a nominal em of one sixth of an inch, approximately 4.2333 millimetres. That sets the outline's scale, rather than the exact ink height of every glyph. A particular x-height or glyph advance can be a different fraction of an em.

The CSS conversion also gives 12 typographic points as 16 CSS pixels. A CSS pixel is a layout unit, so this equality does not promise 16 hardware pixels or a ruler-measured physical height on every screen. Zoom and the mapping to device pixels must be accounted for separately; the device pixel ratio records one part of that mapping.

The x-height is the height of the main lowercase body of a typeface, conventionally associated with the letter “x”. It excludes the extra extent of ascenders and descenders; the cap height describes a different reference. Small optical overshoots mean that not every lowercase outline without an ascender has exactly the same ink height.^[ref]

Write $r$ for the x-height as a fraction of an em. At nominal scale $p$ pixels per em, its ideal scaled height is $rp$ pixels, before grid fitting. Equal font sizes do not force equal $r$, so changing the typeface can alter the apparent lowercase size.

To preserve a target height $h$ while switching to a design with ratio $r_2>0$, choose $p_2=h/r_2$. If the original ratio was $r_1$ at scale $p_1$, this becomesFor a hypothetical switch from $r_1=0.5$ at 16 pixels per em to $r_2=0.4$, the matching scale is 20 pixels per em. Both lowercase bodies then have ideal height 8 pixels. This is the geometry behind metric-based font-size adjustment when a fallback font replaces another.^[ref]