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.

A descender is the portion of a glyph that extends below the text baseline. Lowercase “p”, “q” and “y” commonly have one; the exact form depends on the typeface. A descender describes the visible shape relative to the writing reference, rather than the distance through which the logical pen position advances.^[ref]

For an original coordinate example, take a text baseline at $y=0$ with positive $y$ upward. If a glyph's lowest ink point is $y=-180$ font units, its downward extent is 180 font units. At a scale of 20 pixels per em with 1000 font units per em, this becomes 3.6 pixels before grid fitting. The extent is positive even though the lowest coordinate is negative.

The font descent is a related global layout metric, with sign conventions that depend on the format or API. It need not equal the downward extent of each individual descender. Line height and neighbouring ink extents together determine whether forms on successive lines collide; the nominal font size alone does not decide that.

An em is a nominal typographic length set by the current font size. At a font size of $S$ typographic points, one em is $S$ typographic points long.^[ref] A scalable computer font describes its geometry relative to this scale. In OpenType, unitsPerEm specifies how many font units make one em.^[ref]

Suppose one em contains 2048 font units. A design length of 1024 font units is half an em. At a font size of 12 typographic points, that length is 6 typographic points; at 18 typographic points, it is 9 typographic points. The stored coordinate has not changed; the scale has.

The word em does not require the glyph for “M” to be exactly one em wide. Nor is an em the measured ink height of every glyph: a shape can occupy only part of the nominal square or extend beyond it.^[ref] Glyph advances, left side bearings and right side bearings must consequently be read from the computer font's metrics rather than inferred from the em alone.

The font ascent is an upward metric measured from a text baseline and used when allocating vertical space for a font. It describes the font's layout metrics as a whole, rather than the visible ascender of one particular glyph. A short letter, a tall letter and an accented form can therefore share the same font ascent while having different ink bounding boxes.^[ref]

Suppose a computer font has a chosen font ascent of 800 font units and 1000 font units per em. At 20 pixels per em, the scaled upward metric is 16 pixels. This calculation allocates a reference extent; it does not assert that the letters being drawn actually reach 16 pixels above the text baseline.

The field used must be stated. OpenType provides ascender in hhea and sTypoAscender in OS/2, while some older layout paths use other metrics. The sTypoAscender, sTypoDescender and sTypoLineGap fields are intended to work together for typographic line spacing. Their ascent-minus-descent need not equal unitsPerEm.^[ref]

Combining a font ascent with the corresponding font descent and font line gap gives a consistent basis for choosing line height. Mixing fields chosen under different conventions can instead change the spacing even when the nominal font size is unchanged.

The font descent supplies the below-text baseline part of a font's vertical layout metrics. It must be distinguished from the descender of an individual glyph. The coordinate convention also matters: a downward extent can be represented as a negative coordinate in a system whose vertical axis points upward, or as a positive distance in another API.^[ref]

For example, a signed descent $d_f=-200$ font units represents a downward extent $D=200$ font units. With 1000 font units per em and 20 pixels per em, its magnitude scales to 4 pixels. Calling that a negative height would confuse the coordinate with the distance being allocated.

Using a signed descent, an ascent $a=800$ and a font line gap $g=200$ in the same font units givesEquivalently, if $D=-d_f$ is the positive downward extent, the same line height is $h=a+D+g$. This is the elementary typographic spacing model; the rendering system's choice of metrics must still be respected.^[ref]

A computer font can contain several descent-related fields. For example, OpenType's hhea header stores a typographic descender; an application must not infer the sign and purpose of every other API field merely from the word descent.^[ref]

A font line gap is a font-wide metric giving an additional spacing allowance to combine with font ascent and font descent. For an elementary default line-spacing calculation using signed descent $d_f$,where $a$ is the ascent and $g$ the font line gap. OpenType's sTypoLineGap is intended to be used with the matching sTypoAscender and sTypoDescender fields.^[ref]

Suppose the chosen metrics are $a=760$, $d_f=-240$ and $g=100$ font units. The default spacing is 1100 font units. With 1000 font units per em at 18 pixels per em, that is 19.8 pixels between text baselines.

The stored font line gap provides an input to a spacing decision. An application can instead request a different line height, and CSS leading is then calculated from that requested height and the selected metrics. Nor does the font line gap measure the visible blank strip between every pair of lines: the ink bounding boxes vary with the particular glyphs. The line height diagram shows this distinction with schematic ink inside larger font-wide metric regions.

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 unit measures distances in a computer font's design coordinates. If one em contains $U$ font units, a coordinate difference $q$ represents $q/U$ of an em. OpenType stores $U$ in the unitsPerEm field of its font-header table; its permitted range is 16–16384.^[ref]

The design coordinate is independent of a particular screen. Before grid fitting, an unrotated uniform scale with $p$ pixels per em sends a horizontal length $q$ toFor example, $U=2048$ and $p=12$ send a length of 512 font units to 3 pixels. Doubling the requested font size doubles that ideal geometric length without changing the stored outline.

A font unit is consequently not itself a pixel. Grid fitting can further change a scaled outline or its glyph advance to suit the pixel grid. Nor does the height of every visible glyph equal one em: the em fixes a scale, while individual glyphs have their own bounding boxes.

A glyph advance is the displacement of the logical pen position after a glyph is processed. In horizontal layout its main component is often called the advance width. The OpenType horizontal-metrics table records an advanceWidth in font units, together with a left side bearing.^[ref]

The advance need not equal the width of the visible glyph's bounding box. A spacing text character can select a glyph with a positive advance and no visible outline. Conversely, a drawn shape can extend beyond its nominal advance, or a positioned accent can have a zero advance. The geometry of the ink and the progression of the logical pen therefore require separate data. In a simple horizontal metric, the advance is the left side bearing plus the ink width plus the right side bearing; overhangs can make a bearing negative.

For a hypothetical pair with advances 600 and 600 font units, a pair adjustment of minus 80 gives a total advance of 1120 font units. The second origin moves 80 font units left of its unadjusted position. No glyph outline needs to change for this kerning operation. The final layout can therefore have different advances from the default values stored for isolated glyphs.

A glyph connector is the end portion of a glyph part intended to overlap a neighbouring part in a mathematical glyph assembly. An OpenType MATH table gives start and end connector lengths along the extension direction: left/right for a horizontal assembly and bottom/top for a vertical one.^[ref]

Let adjacent parts have full advances $a_1,a_2$, joining connector lengths $c_1,c_2$, and minimum overlap $o_{\min }$. An allowed overlap $o$ must satisfyThe bounds come from the available connector material and minConnectorOverlap.^[ref]

For invented dimensions in font units, choose $a_1=600$, $a_2=500$, $c_1=120$, $c_2=90$ and $o_{\min }=50$. Then $50\le o\le 90$, giving $1010\le L\le 1050$. A target extent 1030 requires overlap 70 and is feasible. A target extent 1000 requires overlap 100, exceeding the second connector's length, so this pair cannot produce it.

These are construction advances, rather than measured ink bounds. Connector data permit controlled changes of extent while other geometry keeps the parts aligned. The mathematical glyph assembly still needs placement relative to the text baseline.

In a simple unpositioned horizontal layout, the left side bearing is the signed distance from a glyph's pen position to the left edge of its ink bounding box. Put the logical origin at $x=0$ and call the left ink edge $x_L$. Then $\mathrm{lsb}=x_L$. A positive value leaves space before the ink; a negative value means that the ink overhangs the origin.^[ref]

For example, a glyph whose ink occupies $40\le x\le 540$ and whose glyph advance is 600 font units has left side bearing 40, ink width 500 and right side bearing 60. These are default metrics; subsequent glyph positioning can change the rendered arrangement.

OpenType's horizontal-metrics table supplies the left side bearing and glyph advance. One must not assume that every outline's stored xMin is already the left side bearing: the outline's own coordinate origin and the metrics' logical origin need not coincide in every supported format.^[ref]

The line height governs the vertical spacing allocated to a line of text. For a simple repeated run with fixed metrics, it sets the distance from one text baseline to the next. The gap between visible ink is a separate quantity, because different glyphs need not fill their allocated vertical region.

In an elementary single-font model, let $A$ be the positive font ascent, $D$ the positive magnitude of the font descent, and $G$ an added font line gap. ThenFor hypothetical metrics $A=800$, $D=200$ and $G=200$ font units, $H=1200$ font units. With 1000 font units per em and 20 pixels per em, the text baselines are 24 pixels apart. The line height can thus exceed the nominal font size.

CSS lays out inline content through line boxes. Its line-height participates in that calculation, and a block's declared value sets a minimum rather than guaranteeing that every mixed-content line has exactly that height. A taller inline object or a different alignment can enlarge a line box. The specification also describes how extra typographic leading is split above and below the chosen font metrics.^[ref]

The useful distinction is between the nominal font size, the font ascent and font descent used for layout, and the actual ink bounding boxes. They answer different geometric questions even when they are expressed in the same units.

A mathematical font constant is a font-specific parameter used in mathematical typesetting. The MathConstants portion of an OpenType MATH table supplies distances, percentages and other parameters, including the Math axis offset and script scaling.^[ref]

For an invented distance example, suppose a computer font uses 1000 font units per em and specifies fractionRuleThickness as 40 font units. At 25 pixels per em, the ideal typeset fraction bar thickness isAt 50 pixels per em, the same stored value gives 2 pixels before rasterization adjustments. A percentage value such as 80, however, is a ratio and must not be converted as though it meant 80 font units.

Keeping the units explicit prevents plausible-looking scale errors. Suggested values in the specification guide font design; they are not universal dimensions shared by every computer font.

A mathematical glyph assembly constructs an extended mathematical shape from positioned glyph parts. An OpenType MATH table records each part's full advance and glyph connectors; extender parts may repeat, with overlaps joining neighbouring pieces.^[ref]

For an invented vertical assembly, take bottom, middle and top parts with advances 500, 400 and 500 font units. Give each joining connector length 150 and require at least 80 font units of overlap. Choosing overlaps of 100 is then allowed. Starting at zero puts the parts at offsets 0, 400 and 700, giving total extentRepeating the middle part once, with another 100-unit overlap, adds $400-100=300$ and gives extent 1500. These are construction measurements along the growth direction, not a claim about a particular font's ink bounds. Positioning the assembled shape relative to the text baseline remains a separate layout choice.

A mathematical glyph variant is an alternative ready-made glyph supplied for a mathematical shape at a different extent. In an OpenType MATH table, each MathGlyphVariantRecord pairs a glyph index with its advanceMeasurement along the extension direction.^[ref]

Consider an invented set of vertical variants with construction measurements 900, 1300 and 1800 font units. A selection policy seeking the smallest variant at least 1200 units tall chooses 1300; a target of 1700 chooses 1800. A target of 2000 exceeds the set and may need a mathematical glyph assembly if the font supplies suitable parts.

This discrete choice is useful for growing mathematical delimiters around tall expressions. The numbers are an explanatory selection example, not measurements of an installed computer font. A separately drawn taller glyph can change proportions without requiring every stroke to undergo the same uniform enlargement.

The mathematical typesetting axis, or Math axis, is a horizontal alignment reference for a formula. Its offset from the text baseline is a mathematical font constant, represented by axisHeight in an OpenType MATH table.^[ref]

For an invented coordinate example, choose upward-positive coordinates, put the text baseline at $y=0$, and set the axis offset to $a=250$ font units in a computer font with 1000 font units per em. At 20 pixels per em, the axis is $250(20/1000)=5$ pixels above that baseline. A symmetric enclosing shape spanning $y=-350$ to $y=850$ has midpoint $250$, so its centre lies on the axis.

The typeset fraction bar is another useful alignment cue. The reference fixes relative placement; translating the whole formula also translates its baseline and axis.

Pixels per em specifies the raster scale of one em. If $U$ font units make an em and the requested scale is $p$ pixels per em, a design length $q$ becomes $pq/U$ pixels before grid fitting. The value measures the nominal typographic scale rather than the ink height of an individual glyph.^[ref]

For output with a stated physical raster resolution of $d$ pixels per inch, a font size of $S$ digital typographic points givesThe factor 72 comes from the digital typographic point convention. For example, $S=12$ and $d=144$ give 24 pixels per em; a hypothetical glyph advance of 0.6 em then scales to 14.4 pixels. Doubling $d$ doubles the pixel count while preserving the requested physical length.

Horizontal and vertical pixel density can differ, in which case the two directions have distinct pixels per em. An application can also impose its own screen-to-physical-unit mapping. One must state which scale is being used rather than infer the physical size from a pixel count alone. Rasterization and grid fitting then determine how the scaled geometry becomes a visible image.

The right side bearing measures the signed gap from the right edge of a glyph's ink bounding box to the point specified by its default horizontal glyph advance. If the origin is $x=0$, the advance is $a$, and the ink edges are $x_L,x_R$, thenThus the advance splits into a left side bearing, an ink width and a right side bearing. OpenType uses this relation to derive the right side bearing from the horizontal metrics and outline bounds.^[ref]

For the hypothetical ink interval $40\le x\le 540$ and advance 600 font units, the right side bearing is 60 font units. If a different glyph extends to $x_R=650$ with the same advance 600, its right side bearing is $-50$ font units: ink crosses the next nominal origin. A negative bearing is therefore meaningful rather than an invalid width.

These are metrics of an individual default glyph. Kerning and other glyph positioning rules can change the actual gap between adjacent shapes, so the right side bearing alone does not determine the visual spacing of a whole run.