A bidirectional embedding level is a nonnegative integer used by the Unicode Bidirectional Algorithm to represent directional nesting. A level whose value is an even integer has left-to-right embedding direction; one whose value is an odd integer has right-to-left embedding direction.[ref]
Level values carry more information than parity. For example, levels2 and4 share the same default direction, but they participate differently in level-based reordering of bidirectional text. Higher values indicate more deeply nested directional structure, rather than a greater physical displacement across the screen.
An original supplied-level example uses the list
The level4 pass reverses . The level3 pass reverses that same pair again, the level2 pass reverses it a third time, and the level1 pass reverses the larger middle run. The final physical left-to-right list is . If the intermediate level3 pass were omitted merely because no item had level3, the middle pair would come out in the opposite order.
These are supplied resolved levels for an algebraic illustration, not a claim that arbitrary level arrays arise from any particular unformatted string. Resolving levels from Unicode bidirectional classes, explicit controls and context is an earlier part of the algorithm. The final reversal stage consumes those results.[ref]
A level also differs from a character's original property. A decimal digit can be assigned a level within a surrounding directional context without becoming a different stored code point. Keeping the property, the computed level and the eventual display position separate makes implementation traces easier to check.
Level-based reordering of bidirectional text is the final positional reversal procedure of the Unicode Bidirectional Algorithm after directional levels and line boundaries have been resolved. RuleL2 processes thresholds from the largest level down through the smallest level whose value is an odd integer. Each pass reverses every maximal consecutive run whose levels meet or exceed the threshold.[ref]
An original trace supplies the resolved levels rather than attempting to infer them. Take the logical items
At threshold2, reverse only the two middle digits, obtaining . At threshold1, reverse the entire middle five-item run, giving
The digits underwent two reversals, preserving their internal order. The labels each denote one abstract right-to-left text character; every array is written in physical left-to-right order.
Figure 1.
Descending level passes reverse nested runs and restore the internal order of digits
. Reused supplied-level illustration. It demonstrates ruleL2, rather than a complete implementation that resolves levels, shapes glyphs or chooses line boundaries. Details.
Thresholds include intermediate values that no item happens to have. For example, a pair at level4 surrounded by level1 items participates in passes4,3,2 and then the enclosing pass1. Omitting pass3 changes the result, as the bidirectional embedding level example demonstrates.
An implementation may carry levels with the items, as the figure generator does. It can also locate each reversal range from the original fixed level array: earlier passes permute items only inside higher-level runs, preserving the boundaries of every later lower-threshold run. Keeping logical indices on the displayed items supplies the eventual position map. Line-final whitespace resetting belongs to ruleL1, and combining-mark handling and mirroring require their separate rules.[ref]
Logical text order 2026-11-05
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 as
The 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 , whose source-position list is . 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 . 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]
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 each represent a distinct right-to-left text character, while represent left-to-right text characters. All rows below are written in physical left-to-right order. Start with
The level 2 pass changes the middle digits to . The level 1 pass then reverses the whole five-item middle run, producing
The digits have been reversed twice, preserving their original internal order. Reversing the entire stored sequence once would instead exchange and and leave the digits in the wrong order. This example demonstrates the reordering step, not how all Unicode bidirectional classes are resolved.
Figure 1.
Two level-based reversals preserve the internal order of the digits
. Original illustration with supplied bidirectional embedding levels. The boxes denote individual abstract text characters, not literal multi-character labels. Details.
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 bidirectional class is a character property, formally named Bidi_Class, used as input to the Unicode Bidirectional Algorithm. It classifies directional behavior; the algorithm combines the properties with context to compute bidirectional embedding levels. A class is not itself a final screen position.[ref]
For a compact example, Latin A (U+0041) has classL, Hebrew alef (U+05D0) has classR, digit1 (U+0031) has classEN, and ordinary space (U+0020) has classWS. These labels distinguish strong directions, a numeric class and whitespace. They carry information that a single left-to-right/right-to-left Boolean would lose.
An original data-structure example keeps the stages separate. Represent each stored item by a record containing its logical index, code point, original Bidi_Class, working directional type, resolved level and eventual visual index. A direction-resolution step can update the working fields while leaving the stored code point and original property intact. A later level-based reordering of bidirectional text step changes position mappings rather than assigning new code points.
The advantage appears in debugging a digit within mixed-direction text. Its original classEN identifies a numeric input. Its resolved level describes the computed directional context, and its visual index identifies a placement in one line. Reporting only the visual index would conceal whether a mistake arose during classification, context resolution or final reordering.
The normative property data are supplied by the Unicode character database; broad descriptions such as “a letter in this script” have exceptions. An implementation should use the data for its chosen Unicode version rather than infer every character's class from appearance.[ref]