Word Count: ~2200 · Reading Time: 10 minutes

BiDi Algorithm Rules and Base Paragraph Direction

A deep dive into the foundational programmatic decision: How visual conflicts are resolved and structural sovereignty is enforced over mixed-direction text strings.

The Chaos of Mixed-Direction Text and the Need for Sovereignty

If characters alone were left to determine their position on a screen, rendering mixed-direction text would result in an endless visual tug-of-war. Consider a web page containing Arabic words that inherently flow from right to left, English programming terms that adhere to a left-to-right progression, and neutral punctuation marks or numbers caught in the middle. Without a centralized authority to orchestrate the movement of these disparate elements, a hybrid text string fractures into decoupled linguistic segments, completely losing its logical meaning once converted into a visual layout.

In the foundational article of this series on Zy Yazan Platform, we deconstructed the core logic of Unicode, examining how it segregates a character’s abstract semantic identity (the Code Point) from its physical presentation (the Glyph). However, we concluded with the core dilemma of hybrid text: the fracturing of visual flow when directional contexts collide. The deterministic mechanism engineered to resolve this layout conflict is the Unicode Bidirectional Algorithm, commonly abbreviated as the BiDi Algorithm.

The BiDi Algorithm is not a superficial rendering patch; it is the ultimate traffic controller operating within the core of every modern web browser and operating system. It is strictly deterministic, meaning it leaves nothing to guesswork or heuristics. Instead, it applies a rigid mathematical pipeline to a sequence of code points to output a stable visual order in fractions of a millisecond. At the very heart of this pipeline lies a critical, sovereign step that dictates the behavior of the entire string: establishing the Base Paragraph Direction.

1. Dissecting the BiDi Algorithm: The Three Directional Layers

To understand how the algorithm operates, we must first examine how Unicode classifies human typography. The BiDi algorithm categorizes every character into one of three distinct directional types based on its inherent semantic behavior. This classification forms the bedrock of all subsequent layout decisions:

First: Strong Characters

Strong characters possess an absolute, unyielding directional identity that remains completely unaffected by surrounding text. They are divided into:

• Left-to-Right (LTR) Strong Characters: This includes all Latin alphabets (English, Spanish, French, etc.), Cyrillic, Greek, and Armenian scripts. They are designated with the programmatic type L within the algorithm.
• Right-to-Left (RTL) Strong Characters: This includes Arabic, Hebrew, Syriac, and Dhivehi scripts. They are designated with the programmatic type R, or specifically AL (Arabic Letter) to handle distinct cursive rendering rules later in the pipeline.

Second: Weak Characters

Weak characters do not possess the structural independence of strong characters. Their directional behavior is tightly coupled with numeric contexts. They include:

• European Numbers (EN): The standard Western digits used globally (1, 2, 3).
• Arabic-Indic Numbers (AN): The digits predominantly used in Middle Eastern Arabic contexts (١، ٢، ٣).
• Numeric Separators: Characters like percent signs, decimal points, and thousands separators.

Third: Neutral Characters

Neutral characters are entirely passive. They possess no inherent directionality and act like chameleons, adopting the directional context of their immediate surroundings. This layer includes:

• Whitespace characters (Spaces, tabs).
• Common punctuation marks: The period (.), exclamation mark (!), brackets/parentheses (()), and quotation marks.
• Universal mathematical symbols like the plus sign (+) and minus sign (-).

The core objective of the BiDi Algorithm is to take a raw sequence of these mixed characters ordered by their entry sequence in system memory—known as the **Logical Order**—and process them through state transitions to resolve weak and neutral states, ultimately generating the correct **Visual Order** on the screen.

2. The Sovereign Concept: What is Base Paragraph Direction?

Before the algorithm can process a single line, it requires a structural frame of reference. This global anchor is the Base Paragraph Direction.

The base direction is not a cosmetic layout alignment tool (like CSS text alignment); it is a sovereign algorithmic variable that sets the baseline layout state. It exerts absolute authority over two critical execution steps:

1. Resolving Neutral Punctuation: When a neutral character, such as a period or question mark, sits at the boundary of a sentence or between conflicting directional zones, the base paragraph direction serves as the ultimate tie-breaker. It dictates whether that period is rendered on the far left or the far right.
2. Governing Global Segment Flow: If a paragraph contains a mix of Arabic and English phrases, the base direction determines which language block anchors to the starting margin of the container, and dictates the line-breaking wrap behavior (Word Wrapping).

The absence of an explicitly declared Base Paragraph Direction forces the browser to evaluate text blindly in a state of structural ambiguity. It resorts to guessing the layout context based on the first strong character it encounters—a practice that consistently destroys user interfaces in dynamic localized applications.

3. How the Base Direction is Determined

The Unicode Bidirectional Algorithm standard (UAX #9) follows a strict hierarchy to establish the base paragraph direction. The calculation follows a clear operational order:

1. Explicit Declaration

This is the most reliable engineering practice. The developer explicitly declares the direction directly in the markup or layout rules. On the web, this is achieved using the HTML direction attribute (dir="rtl" or dir="ltr"), or via the CSS direction property (direction: rtl;).

When the rendering engine detects an explicit directive, it skips all fallback detection loops. The declared direction becomes the absolute law governing the algorithm’s initial state.

2. Implicit Detection (The First-Strong-Character Rule)

If the developer fails to define an explicit direction, or when dealing with dynamic, unvalidated user-generated data (such as database fields, tweets, or chat messages), the BiDi algorithm initiates an automatic fallback mechanism called the **First-Strong-Character Rule**:

• The engine parses the raw code points sequentially from the beginning of the memory buffer (Logical Order).
• It systematically ignores all neutral characters (spaces, periods, brackets) and weak characters (numbers).
• The moment the engine hits the first character typed as a strong directional entity, the parsing halts immediately:
  • If that first strong character belongs to the LTR family (e.g., a Latin letter), the entire paragraph’s base direction is permanently locked to LTR.
  • If that first strong character belongs to the RTL family (e.g., an Arabic letter), the entire paragraph’s base direction is permanently locked to RTL.
• If the engine reads the entire string without finding any strong characters (e.g., a string consisting only of digits and exclamation marks), it falls back to the default orientation of the host operating system, which is almost universally LTR.

4. Deconstructing the Visual Catastrophe: An Engineering Breakdown

To fully grasp how this math translates into visual bugs, let us trace how the algorithm handles a hybrid sentence under different configurations. We will explicitly break down the Arabic text so that non-Arabic speakers can follow the exact path of structural failure.

Scenario A: Correct Handling with Explicit RTL (dir=”rtl”)

Here, the parent element is explicitly assigned dir="rtl". The algorithm instantiates with a base direction of RTL. Reading the logical stream, the Arabic words flow from right to left. When the engine encounters the strong LTR tokens React Native, it constructs a temporary directional inline run flowing left-to-right to keep the English words readable. It then drops right back into the dominant RTL flow for the remaining Arabic phrase. Finally, it encounters the neutral period (.). Since the sovereign base direction is explicitly RTL, the algorithm rules that the neutral period must append to the end of the global paragraph flow—which is the far-left margin of the text block. The result renders perfectly:

تطبيق الهاتف يستخدم مكتبة React Native لتطوير الواجهات.

Translation of the rendered output above: “The mobile app uses the React Native library to develop interfaces.” (The period correctly sits at the far left, terminating the Arabic sentence).

Scenario B: The Structural Catastrophe (Implicit LTR Fallback)

Now, let us examine what happens when the exact same sentence structure is flipped to lead with the English technical term, a common occurrence in localization, but lacks an explicit directional attribute:

Because there is no explicit HTML dir attribute on the element, the engine invokes the First-Strong-Character Rule. It scans the string from index zero and immediately encounters the letter ‘R’ in React. Since ‘R’ is a strong LTR character, the algorithm locks the entire paragraph’s base direction to LTR.

The layout engine now sets the global flow from left to right. It renders React Native on the far-left boundary. Next come the Arabic words. Because they are strong RTL characters, they display right-to-left locally as a block, but they are pushed sequentially to the right of the English text. The ultimate layout failure occurs when processing the final period (.). The period is neutral and looks to its surrounding context. To its left sits the Arabic word الواجهات (interfaces), which is strong RTL. But the global sovereign base direction of the paragraph has been locked to LTR. In the event of a conflict between local text runs and the base paragraph direction, the algorithm favors the base direction. Consequently, the period is forced to the absolute end of the LTR progression—which means it jumps completely across the text and displays immediately to the right of the English words, utterly shattering the readability of the sentence:

React Native .هي المكتبة المستخدمة في تطبيق الهاتف لتطوير الواجهات

Visual breakdown of the bug above: Notice how the trailing period (.) has broken away from the end of the sentence and is now misplaced, wedged visually between the English words “React Native” and the Arabic text. This layout corruption happened entirely because the browser evaluated the paragraph’s base direction as LTR.

5. Quick Reference: BiDi Directional Classifications

To assist in your implementation workflows, this table outlines how the Unicode BiDi Algorithm classifies and treats primary character groups during the layout resolution phase:

Conclusion: The Key to a Radical Solution

Understanding the mechanism that determines a paragraph’s base direction represents half the journey toward building digital platforms that respect the visual identity of the Arabic language while efficiently handling interwoven foreign languages. We have seen how neglecting explicit definition and relying on the “first strong character” rule is an unsafe engineering gamble that inevitably destroys reading flow and isolates neutral punctuation marks.

The ultimate solution does not rely on guesswork; rather, it requires developers to wield strict control tools that programmatically enforce the correct contextual sovereignty. But what if we have fully dynamic text whose content cannot be predicted in advance? And what if we set the entire paragraph direction to RTL, yet want to protect a specific English phrase within the line from colliding with surrounding numbers?

References:

1. Unicode Standard Annex #9: Unicode Bidirectional Algorithm
2. W3C Internationalization Authorization: Structural markup and right-to-left text in HTML
3. WHATWG HTML Living Standard: The directional attribute requirements

Zy Yazan Platform © 2026