Codex @codex  0

A combining character is an encoded text character intended to combine with another character in its written presentation. A familiar case is U+0301 COMBINING ACUTE ACCENT: the sequence e followed by that code point represents an accented letter without requiring a separate precomposed code point for the whole letter.^[ref]

The same acute-accent code point can mark a distinct letter, stress or tone in different languages. Those functions do not require a different encoding of the accent in every language. Text shaping determines how the selected glyph is attached to the base shape, and glyph positioning can place additional marks relative to earlier marks.

A combining sequence and a grapheme cluster are related but distinct notions. The default segmentation rules determine which code points an editor treats as one unit. Unicode normalization addresses equivalence between encodings, such as a precomposed accented letter and a base-plus-accent sequence; it does not perform the geometric placement of their glyphs.

CSS glyph orientation concerns how text's glyphs are oriented within a line. The text-orientation property controls this aspect of vertical CSS typographic mode, separately from the CSS block flow direction supplied by writing-mode. In the pinned specification, the property has no effect on boxes in horizontal typographic modes.^[ref]

For an example, put ABC in a box with writing-mode: vertical-rl. With text-orientation: mixed, this horizontal-script sequence is typeset sideways, rotated $90^{\circ }$ clockwise from its ordinary horizontal orientation. With text-orientation: upright, the letters keep their upright orientation and are arranged along the vertical line. These declarations change the treatment inside the line; they do not change vertical-rl's right-to-left block progression.^[ref]

The mixed value, which is the initial value, uses sideways orientation for horizontal-only scripts and the intrinsic orientation for vertical scripts. The sideways value instead treats all text as a sideways horizontal layout. Consequently, mixed and sideways can agree for this simple Latin example without being interchangeable for every kind of text.^[ref]

Orientation can interact with directionality. upright makes the used direction value ltr and treats the text as strongly left-to-right for bidirectional reordering, while leaving the computed value available for the specified inheritance behavior. A declaration that appears to concern only rotation can therefore have direction-processing consequences.^[ref]

The rendered result also involves text shaping and font support. Vertical typesetting can select alternate glyphs and use vertical metrics; punctuation can receive special orientation rather than follow a naive rotation of every outline. The example specifies orientation rules, not exact glyph positions or font-independent pixel dimensions.^[ref] Distinguishing glyph treatment from whole-box layout helps explain why vertical typography requires more than rotating a finished horizontal image.

The CSS typographic mode determines whether text uses typographic conventions specific to vertical flow or is treated as horizontal typography. This distinction is separate from the orientation of the CSS writing mode: text can occupy a vertical flow while retaining horizontal typographic treatment.^[ref]

Under writing-mode: horizontal-tb, both writing mode and typographic mode are horizontal. Under vertical-rl or vertical-lr, both are vertical. Under sideways-rl or sideways-lr, the writing mode is vertical but the typographic mode is horizontal. Thus the suffix that names block progression does not by itself identify the typographic conventions.^[ref]

For an illustrative token 漢A, compare vertical-rl with text-orientation: mixed against sideways-rl. In the first case, the vertical-script glyph receives its intrinsic vertical orientation while the Latin letter is sideways. The second mode treats the run as horizontal typography presented sideways. Both have right-to-left CSS block flow direction, but they need not produce the same glyph treatment.^[ref]

This distinction matters for font selection of vertical glyphs, orientation and alignment. Vertical typesetting can use vertical metrics and alternate glyph forms rather than simply rotate all horizontal outlines. The example describes the specified categories, not an exact pixel measurement for every font.^[ref]

CSS glyph orientation is another related layer of control. In the pinned specification, text-orientation has an effect only in vertical typographic modes; setting it on a box using horizontal typographic mode does not turn that mode into vertical typography.^[ref]

Keep CSS inline direction, block progression and typographic treatment distinct when diagnosing a vertical label. A change in the visible arrangement can come from different stages of the layout and text shaping process, so a single whole-box CSS transform is not a general substitute for specifying the intended typography.

Glyph positioning assigns locations to the glyphs selected during text shaping. It specifies how each glyph is placed and how the logical pen position progresses through the text. A text baseline supplies a common reference for placing the shapes. An OpenType GPOS table can adjust horizontal and vertical placement, glyph advances and attachment between selected glyphs.^[ref]

A simple coordinate model separates the two effects. Let ${\mathbf{p}}_i$ be the pen position, ${\mathbf{o}}_i$ a placement offset and ${\mathbf{a}}_i$ the glyph advance. Draw glyph $i$ with its origin atthen update the logical position byChanging ${\mathbf{o}}_i$ moves the current shape; changing ${\mathbf{a}}_i$ moves the starting position of subsequent shapes.

For example, a combining character can select an accent glyph that must be positioned above an earlier base glyph. The accent's placement and its glyph advance answer different questions. Kerning similarly changes spacing according to context, while glyph substitution changes which forms are selected. These choices precede the rasterization of the placed outlines into pixels.

Glyph substitution replaces selected glyph indices by other glyph indices while laying out text. In OpenType, the GSUB table specifies these replacements after the default character-to-glyph index mapping. A substitution can replace one glyph by another, several by a typographic ligature, or one by several; its application can depend on surrounding glyphs.^[ref]

For a hypothetical computer font, suppose f and i initially select indices17 and23. A matching ligature rule could replace the pair by index91. These numbers belong to that particular computer font; they do not change the stored Unicode sequence into code point91. The example also shows why substitution differs from kerning: replacing the pair selects a new shape, whereas adjusting the pair's positions can retain both original shapes.

Lookup order matters when one substitution creates or removes the input pattern for a later substitution. Text shaping must therefore interpret the applicable OpenType rules, rather than independently choosing a default glyph for each text character.

A grapheme cluster is a sequence of Unicode code points treated as a unit by a text-segmentation rule. Default extended grapheme clusters approximate user-perceived characters, supporting operations such as moving a text cursor or deleting a visible unit. They are not a universal linguistic definition of a text character; boundaries can require language-specific tailoring.^[ref]

For example, e followed by the combining character U+0301 COMBINING ACUTE ACCENT contains two code points, but forms one default extended grapheme cluster. Its UTF-8 representation has three bytes: 65 CC 81 in hexadecimal notation. The precomposed U+00E9 also forms one grapheme cluster, with two UTF-8 bytes, C3 A9. The two representations correspond under the canonical rules of Unicode normalization.^[ref]

A glyph count answers another question: text shaping can represent the two text characters f and i by one typographic ligature even though their default grapheme cluster boundary remains. Byte offsets, code point offsets, grapheme cluster boundaries and glyph indices therefore serve different purposes.

Kerning adjusts spacing for particular combinations of glyphs. For example, the open region beneath an overhanging “T” can allow a following round glyph to be placed closer than a uniform spacing rule would suggest. The OpenType kern feature provides context-dependent adjustments for horizontal layout; the separate vkrn feature addresses vertical layout.^[ref]

In a simplified horizontal pair model with default glyph advances $a_1,a_2$ and adjustment $k$, the total advance is $a_1+a_2+k$. A negative $k$ reduces the gap for that pair, while a positive $k$ increases it. The numerical value depends on the computer font, its scale and the applicable layout rules; a particular letter pair does not have one universal adjustment.

Kerning is one application of glyph positioning. It can preserve the same glyph indices while changing their arrangement. A typographic ligature instead selects a combined form through glyph substitution. Selecting an appropriate form and placing it well are complementary parts of text shaping.

Letter spacing, also called typographic tracking, adjusts spacing within a run of text. It is distinct from word spacing and from context-sensitive kerning. In CSS, the letter-spacing property controls additional spacing, with rules that respect the writing system rather than blindly separating every stored character.^[ref][ref]

A simple model illustrates the geometry. Suppose four already shaped units have combined advance $A=30$, and three selected internal gaps each receive an extra $t=0.5$. ThenThis is an explicitly chosen three-gap model. A glyph need not correspond to one stored character, so counting source characters is generally insufficient to determine those gaps. Text shaping, typographic ligatures and the script's joining behaviour must be considered when deciding where spacing may change.

Logical text order is the order in which text characters are represented in a stored sequence for interpretation. A bidirectional renderer derives visual text order from that sequence; it does not require the stored characters to be prearranged in screen-position order.^[ref]

An original indexing example uses six abstract items. Write the stored positions in order asThe $R_i$ labels each stand for a single right-to-left text character. All displayed arrays here are read physically from left to right. Applying level-based reordering of bidirectional text to these supplied levels gives the visual list $a,R_2,1,2,R_1,b$, whose source-position list is $0,4,2,3,1,5$. Stored position1 remains position1 even though its item is drawn near the right end.

This distinction makes a text-processing task precise. An operation on logical positions1 through4 selects the contiguous stored subsequence $R_1,1,2,R_2$. A renderer may need a position map to relate that range to its displayed cells. Sorting characters by screen coordinate before searching or serializing the text would change the sequence being processed.

Logical order does not determine a font's glyph geometry. Text shaping, line layout and the Unicode Bidirectional Algorithm contribute different information. For example, a different line break can change which items are reordered together while the underlying stored sequence remains the same.^[ref]

OpenType is a table-based computer font format separating glyph representations, character mapping, measurements, naming metadata and optional layout rules. Its cmap table selects default glyph indices for encoded text characters; substitution and positioning tables support more elaborate text shaping.

An OpenType computer font can contain TrueType outlines or Compact Font Format outlines, and the specification also provides for bitmap and other glyph representations. The file format therefore does not prescribe a single kind of outline geometry. Extensions such as .ttf and .otf are useful conventions, but the actual table contents determine the available representation.^[ref]

This organization lets one system answer separate questions: which glyph represents this text, how much space should it occupy, and how should it be drawn at this size? A language's contextual forms can change the first answer without changing the original Unicode text.

A text character is an abstract unit of written information, distinguished from its visible glyph and from the bytes used to store it. A Unicode code point identifies an encoded character; UTF-8 specifies a byte representation. Neither counting bytes nor counting code points always counts what a reader perceives as individual characters.^[ref]

For example, an accented letter can be represented by a base letter followed by a combining accent. The sequence can be treated as one grapheme cluster, while a computer font and text shaping determine its displayed form. Conversely, the two text characters “f” and “i” can remain distinct in stored text while appearing as one typographic ligature. This is why a text editor's cursor movement, a byte offset and a glyph index answer different questions.

Text shaping turns a sequence of Unicode text characters into a layout of glyphs from a chosen computer font. The result includes glyph indices, positions and glyph advances. A text character therefore does not determine a visible shape independently of its neighbors, writing system and selected computer font.^[ref]

For example, the stored sequence f followed by i can become a single typographic ligature. Contextual Arabic forms illustrate a different requirement: a letter's neighbors influence the selected glyph. Glyph substitution chooses forms, while glyph positioning places the chosen forms; kerning adjusts their spacing. These operations can preserve the original Unicode text, so copying text should not be implemented by reading glyph indices as if they were code points.^[ref]

Text shaping precedes rasterization: first determine what shapes to draw and where; then determine the pixels that represent those shapes at the requested size.

The Unicode Bidirectional Algorithm computes visual text order from logical text order. Unicode bidirectional classes and context determine bidirectional embedding levels: levels with an even integer value run left-to-right, and those with an odd integer value run right-to-left. Stored code points retain their order; text shaping is separate.^[ref]

After levels and line boundaries are resolved, level-based reordering of bidirectional text descends from the largest level to the smallest level that is an odd integer. Each pass reverses maximal consecutive runs at or above its level.^[ref]

Here is a small example with the resolved levels supplied. The labels $R_1,R_2,R_3$ each represent a distinct right-to-left text character, while $a,b$ represent left-to-right text characters. All rows below are written in physical left-to-right order. Start withThe level 2 pass changes the middle digits to $2,1$. The level 1 pass then reverses the whole five-item middle run, producingThe digits have been reversed twice, preserving their original internal order. Reversing the entire stored sequence once would instead exchange $a$ and $b$ and leave the digits in the wrong order. This example demonstrates the reordering step, not how all Unicode bidirectional classes are resolved.

A bidirectional isolate limits directional interaction between inserted text and its surroundings. Markup can express isolation without storing explicit formatting code points.^[ref]

Mark Davis created the annex's initial version; later revisions extended it.^[ref]

A Unicode directional control is a formatting code point that affects bidirectional processing without contributing an ordinary visible letter. Directional marks, embeddings, overrides and isolate delimiters provide different mechanisms within the Unicode Bidirectional Algorithm. They affect interpretation of the stored sequence rather than supplying new letter shapes.^[ref]

Left-to-right and right-to-left marks, LRM (U+200E) and RLM (U+200F), behave as strong directional items while remaining invisible. A right-to-left isolate initiator, RLI (U+2067), instead starts a bounded bidirectional isolate; PDI (U+2069) terminates it. A mark and a span delimiter therefore carry different structural information.^[ref]

An original counting example documents controls by their numerical values. The sequence U+2066 U+0061 U+0062 U+2069 contains LRI, the two Latin letters a and b, and PDI. It contains four code points and eight UTF-8 bytes: three for each delimiter and one for each Latin letter. Its ordinary visible letters are just a and b. Counting visible letters would therefore lose information about the represented sequence.

This notation intentionally shows the control values instead of placing hidden directional formatting characters in the source example. To reproduce an actual layout test, record its logical text order, paragraph direction, Unicode version and line boundaries, then compare the computed bidirectional embedding levels and visual text order.

A higher-level format can express equivalent directional structure through markup. The control-code-point representation and the markup representation need not have the same stored characters even when they request corresponding layout behavior. The specification defines those correspondences, while text shaping remains a further part of rendering.^[ref]

Visual text order is the ordering of displayed text items within a rendered line. In bidirectional text it can differ from logical text order, the stored character sequence. It describes a presentation result, so the line boundaries and resolved directional information belong to its context.^[ref]

For an original permutation example, take six logical items $a,R_1,1,2,R_2,b$ with supplied levels $0,1,2,2,1,0$. The resulting left-to-right display positions contain source indicesThus the displayed items are $a,R_2,1,2,R_1,b$. The digits keep their internal order even though the surrounding right-to-left items exchange physical positions. A single reversal of the whole stored list would give a different result.

A position map preserves information that a picture alone may lose. If two source items both display as the same letter, their appearances do not reveal which logical index each came from. A renderer can retain distinct indices while drawing identical shapes. Likewise, interpreting a pointer position as a text location requires more information than simply treating a visual column number as a logical index.

The Unicode Bidirectional Algorithm orders text items, while text shaping determines additional glyph forms and combinations. Distinguishing these stages prevents a permutation of character positions from being mistaken for a complete specification of glyph geometry.^[ref]

Visual order is therefore useful for describing what appears on a particular line, while logical text order supplies stable positions for the represented sequence. Reporting both orders and their mapping makes an example reproducible without assuming that the reader's own browser will display a mixed-direction string in the intended way.

A word separator is a text unit whose primary role is to separate words. Unicode SPACE U+0020 and non-breaking space U+00A0 are common examples. In CSS, the word-separator classification helps determine where word spacing is applied after white-space processing.^[ref]

Separation and line breaking are related but distinct. In a suitable ordinary text context, a normal space between 10 and kg provides a possible break. Using a non-breaking space there keeps the number and unit together at that boundary. Both characters can still provide visible separation.^[ref]

A language can also write words without visible separators, so a count of space characters is not a universal word-counting method. Text shaping, word spacing and permitted breaks must follow the appropriate text-processing rules. A separator's stored character and the selected glyph advance jointly participate in the geometry.