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.

A bounding box is a rectangle, or its higher-dimensional counterpart, containing a specified set. For finitely many points, the smallest axis-aligned box is ${\prod }_j[{\min }_i{x}_{ij},{\max }_i{x}_{ij}]$. For $(1,4),(3,-1),(2,2)$ this is $[1,3]\times [-1,4]$. Every coordinate extreme forces the corresponding box endpoint, proving minimality for the chosen axes. Allowing a rotation changes the optimization problem. Disjoint bounding boxes certify disjoint enclosed objects and accelerate geometric searches.

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 scroll margin supplies outsets around an element's transformed border bounds to define its CSS scroll snap area. The scroll-margin shorthand assigns top, right, bottom and left values using the usual one-to-four-value ordering. In the pinned specification these values are lengths, rather than percentages.^[ref]

For an own example, let an untransformed CSS border box occupy $[200,300]\times [100,150]$ in content coordinates measured in CSS pixels. Set scroll-margin: 20px 10px;. The first value applies at top and bottom, and the second at left and right, giving the snap areaThe box itself is still $100$ by $50$ pixels; the alignment region is $120$ by $90$.

Suppose a reachable horizontal start alignment should place this area's left edge at coordinate $30$ within the CSS snapport. With a left-to-right horizontal convention, the candidate offset satisfies $190-s_x=30$, giving $s_x=160$. Without the left outset, it would instead be $200-30=170$. The extra target-side room changes the alignment computation without changing where the border is laid out in the content.

The construction uses the axis-aligned bounding box of the transformed border box before adding the outsets. A rotated CSS transform can therefore affect the base rectangle, even though the resulting snap area remains rectangular in the scroll container's coordinates.^[ref]

CSS scroll margin and ordinary layout margins serve different purposes. The former does not assign this extra space between neighboring elements in normal layout. It is also distinct from CSS scroll padding, which adjusts the viewing/alignment region on the container side.

The specification recommends using the snap area for fragment targets and scrollIntoView() targeting even when snapping is disabled or does not apply to the element. The property can consequently express useful target-side breathing room beyond a mandatory snapping interaction.^[ref]

A CSS scroll snap area is the target region aligned within a CSS snapport during CSS scroll snapping. The specification constructs it from the target's transformed CSS border box: find its rectangular bounding box, aligned to the scroll container's coordinate axes, then apply the outsets supplied by CSS scroll margin.^[ref]

Consider an untransformed element whose border box occupiesin content coordinates measured in CSS pixels. Set scroll-margin: 10px 20px 30px 40px;, in top/right/bottom/left order. The snap area becomesIt is $160$ pixels wide and $80$ high, even though the original border box remains $100$ by $40$.

For a candidate start alignment, suppose the CSS snapport begins at viewport coordinates $(40,10)$ and is large enough to contain this area. Use a horizontal left-to-right writing mode and assume adequate reachable scroll ranges. The required offsets satisfygiving $(s_x,s_y)=(420,80)$. At that position, the element's actual border box appears at $[80,180]\times [20,60]$; the extra room comes from aligning the larger snap area, not moving its borders relative to its content.^[ref]

A CSS transform can change the initial bounding rectangle. The snap area is nevertheless axis-aligned in the scroll container's coordinate space, even if the transformed border is rotated. Its rectangular shape is therefore an alignment construction, not necessarily the painted outline of the element.

CSS scroll margin also differs from an ordinary layout margin: the example's outsets enlarge the snapping region without assigning extra space between neighboring boxes in normal layout. Reachability and visibility still constrain valid snap positions. If an exact alignment would require scrolling beyond the available area, the specification uses the reachable position as far toward that alignment as possible.^[ref]

A CSS transform changes the coordinate mapping used to render a transformable element. Translation, scaling and rotation are examples of CSS transform functions. Their composition maps local points into the parent coordinate system; the CSS transform origin specifies the point around which the transformation is constructed.^[ref]

For an own two-dimensional example, use an ordinary CSS box with transform-box: border-box; transform-origin: 0 0;, no ancestor transforms, and local coordinates relative to that top-left origin. This fixes the CSS transform reference box and origin explicitly. Ignore the box's placement offset to isolate the transform itself.

Using homogeneous column vectors, letThe list transform: translate(10px, 0) scale(2); gives the product $TS$. Applied to point $(3,4,1{)}^{\mathsf{T}}$, the scale acts first:Reversing the list to scale(2) translate(10px, 0) gives $ST$ and the result $(26,8,1{)}^{\mathsf{T}}$. The translation is scaled in the reversed composition. Matrix multiplication explains the order dependence.^[ref]

The zero origin is part of the example, not an irrelevant decoration. A different origin adds translations around the listed operations and can change the mapped point. The simple matrix computation also fixes its column-vector convention instead of relying on an ambiguous phrase such as applying functions in order.

For boxes governed by the CSS box model, a transform changes rendering without rearranging the surrounding normal-flow content. It can nevertheless extend CSS overflow, and transformed geometry affects client rectangles. The absence of normal-flow re-layout is therefore not a claim that every geometrical or scrolling quantity stays fixed.^[ref]

The same transformed bounds matter when constructing a CSS scroll snap area. A rendered border can be rotated while its axis-aligned bounding box is used for alignment geometry. Separating layout boxes, coordinate mappings and derived bounds makes these effects easier to calculate.

The effective convolution kernel size is the bounding extent of a dilated convolution kernel along a spatial axis. For $k$ sampled coefficients with convolution dilation $d$, their offsets are $0,d,2d,\dots ,(k-1)d$. The first-to-last displacement is $d(k-1)$, so including the first position givesThis extent determines the kernel footprint used in spatial shape calculations; it is not generally the number of coefficients.^[ref]

For a two-dimensional example, choose a sampled kernel shape $(3,2)$ with dilation $(2,3)$. Its row offsets are $\{0,2,4\}$ and column offsets are $\{0,3\}$. The bounding shape is thereforeThere are six sampled spatial positions inside a twenty-position bounding box. Fourteen intermediate positions are absent from the sampling pattern.

With three input neural network channels and four output channels, ordinary dense channel connectivity usesweights and optionally four biases, giving $76$ parameters. A general dense five-by-four kernel with the same channel counts would have $240$ weights. Representing the dilated operation that way would require $168$ of them to be fixed zeros, rather than independently learned parameters.^[ref]

For an unpadded $9$-by-$10$ input and convolution stride one, the output grid isMore generally, for one axis with symmetric zero padding $p$ and stride $s$,when the padded input accommodates the footprint. The floor function counts admissible filter origins.^[ref]

The effective size is a geometric quantity for one layer. The complete neural network receptive field through several layers additionally depends on their kernels, strides and connections. Likewise, changing stride moves the spacing of origins; changing dilation changes the footprint at each origin. Keeping bounding extent, sampled-position count and learned-parameter count separate avoids confusing three different sizes.

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.

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.

A font metric is a numerical measurement used to position text from a computer font. Measurements include glyph advances, glyph bearings, bounding boxes and face-level quantities such as font ascent, font descent and font line gap. These describe both logical movement and the geometry of the visible shapes.^[ref]

For a horizontal example, put the pen position at $x=0$, let a glyph have advance 12, and let its ink extend from $x=-2$ to $x=9$. Its ink width is $9-(-2)=11$, while the next pen position is $x=12$. The negative left glyph bearing describes an overhang; it does not imply a negative glyph advance.

A separate example illustrates vertical conventions. With font ascent $a=12$, signed descent $d=-3$ and font line gap $g=2$, the metric-based baseline separation isSome font formats store the descent magnitude with the opposite sign, so the convention must be checked before using the formula.^[ref] These measurements inform layout before rasterization determines the actual pixels.

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.

Typographic leading concerns vertical spacing between lines of type. The term comes from the thin lead spacers used to separate lines of metal type. In current discussion, one must establish whether a quoted value means the complete spacing between text baselines or an additional allowance beyond the chosen font ascent and font descent.^[ref]

CSS leading uses the additional-allowance convention. If a single font contributes ascent $A$ and descent magnitude $D$, and the chosen line height is $H$, thenThe elementary inline-box construction allocates half of $L$ above the ascent and half below the descent. These quantities are font-wide metrics, rather than the actual ink bounding box of each glyph.^[ref]

For hypothetical metrics $A=11$, $D=3$ and $H=18$ CSS pixels, the extra leading is 4 CSS pixels, with 2 on each side. If the same metrics use $H=12$, then $L=-2$: the allocated line region is smaller than the metric extent. Negative CSS leading is allowed, so visible ink can extend outside its line allocation. A line height value must consequently be interpreted together with the font and the layout convention.

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.

In glyph positioning, the pen position is the logical point from which the next glyph is placed. The word pen describes a layout convention: the renderer can draw an outline or a collection of pixels rather than trace a physical pen stroke. Simple horizontal layout places this reference point on the text baseline.^[ref]

Let ${\mathbf{p}}_i$ be the current pen position, ${\mathbf{o}}_i$ a placement offset and ${\mathbf{a}}_i$ the resolved glyph advance. The current glyph's drawing origin and the next logical point are, respectively,For example, in one horizontal coordinate system, ${\mathbf{p}}_i=(10,20)$, ${\mathbf{o}}_i=(-1,2)$ and ${\mathbf{a}}_i=(8,0)$ draw at $(9,22)$ but leave the next logical point at $(18,20)$. Moving the current shape and changing the progression of the run are separate operations.

A glyph's bounding box is therefore not a substitute for its pen position. A left side bearing can leave space between the logical origin and the ink, and a right side bearing records how the ink ends relative to the default advance. Kerning or attachment of a combining character can modify the placement or progression without changing the stored outline.

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.

A text baseline is the reference line used to align glyphs in a run of text. It supplies a placement reference rather than the edge of every visible shape. In a horizontal coordinate system with the baseline at $y=0$, a descender can extend below the line, while an ascender extends above the main body of a lowercase letter. Aligning ink bounding boxes at their bottom edges would therefore fail to align the writing.^[ref]

The reference depends on the writing system and layout. OpenType distinguishes an alphabetic baseline (romn), a hanging baseline (hang) and a mathematical baseline (math), among others. The last is the reference about which mathematical forms are centred; it need not coincide with the alphabetic baseline. Vertical layout also requires an appropriate baseline convention.^[ref]

For a simple horizontal run, start the logical pen position at $(x_0,y_0)$ on the chosen text baseline. A glyph advance $(a,0)$ moves the next pen position to $(x_0+a,y_0)$. A vertical placement adjustment can move an accent glyph while leaving that baseline and the subsequent logical positions intact. This distinction lets glyph positioning align the run while placing individual forms precisely.