BiDi debugger

Microsoft Word (all platforms)

• Toolbar: Home tab → look for two paragraph icons with LTR / RTL arrows. Click the RTL one for the current paragraph.
• Keyboard: Ctrl + Right-Shift (Windows) or Cmd + Ctrl + Right-Shift (macOS) → RTL paragraph. Ctrl + Left-Shift / Cmd + Ctrl + Left-Shift → LTR paragraph.
• If the RTL buttons don't appear, go to File → Options → Language and enable a right-to-left editing language (Hebrew, Arabic, Persian, Urdu). Word hides the RTL controls until it knows you need them.

Google Docs

• Menu: File → Language → pick Hebrew / Arabic / Persian / etc. That enables RTL paragraph controls in the toolbar.
• Toolbar: paragraph-direction buttons appear next to the alignment buttons (the ones with numbered lines). Click the RTL one.
• Keyboard: Ctrl/Cmd + Shift + E, then P to open the paragraph settings, or just click the toolbar buttons directly.

Apple Pages / Numbers / Keynote

• Menu: Format → More → Writing Direction → Right to Left. Applies to the selected paragraph or text box.
• System-wide RTL cursor keys: System Settings → Keyboard → Text Input → Advanced→ check "Move cursor visually in RTL text."

Gmail / Outlook

• Gmail: Settings (gear) → See all settings → Generaltab → "Right-to-Left editing support" → "Enable." A tiny direction-toggle button appears in the compose toolbar after that.
• Outlook desktop: Same paragraph shortcuts as Word — Ctrl + Right-Shift and Ctrl + Left-Shift. Outlook Web uses the same RTL button as Gmail (once enabled in settings).

iMessage / WhatsApp / Slack / Telegram / Discord

• Message text is normally dir="auto"— the app infers direction from the first strong-typed character. Start a message with Hebrew or Arabic → the whole bubble renders RTL, punctuation lands correctly. Start with English → LTR. So the fix is often "type the RTL word first."
• If a message mixes languages and renders wrong, iOS and Android both support long-press → Select All → change paragraph directionin most text fields. Look for a "paragraph direction" or arrow icon in the context menu.
• Slack has no per-message direction toggle. Content is always dir="auto"; if your message renders wrong, reorder so the first word is in the intended direction, or wrap with FSI…PDI from the plain-text section below.

Browsers (Chrome, Safari, Firefox)

• Most form fields on the web are dir="ltr" by default (the classic period-jump cause). You can't change this without editing the site's HTML.
• Workaround in any text field: type an RLM (U+200F) at the very start of your text. On Mac, System Settings → Keyboard → Text Input → Show Input menu, then Input menu → Show Character Viewer → search "RLM" → double-click to insert. On Windows, Alt+X after typing 200F in supported fields.
• Or install a browser extension like "Force RTL" that adds a direction toggle to every text field.

Adobe Photoshop, Illustrator, InDesign (all recent versions)

Adobe ships these in two flavors: the North American / International English edition (default when you install from Creative Cloud) and the Middle East & North Africa edition. Only the MENA edition ships the Middle Eastern text composer that handles Arabic joining, Hebrew punctuation, RTL paragraphs, and kashida.

Switch editions (recommended):

• Creative Cloud desktop app → click your profile picture → Preferences → Apps → Default install language → change to English (Arabic) or English (Hebrew). Then reinstall Photoshop / Illustrator / InDesign — the new install includes the Middle Eastern composer.
• Your files stay compatible with the standard edition; you get all the same tools PLUS the MENA features.

Enable RTL in the MENA edition (per document):

• Character panel: language dropdown must be set to Arabic / Hebrew / Persian for the text to shape correctly. Even in the MENA edition, if language is "English" the Arabic letters render as isolated forms.
• Paragraph panel: use the "Middle Eastern & South Asian Every-Line Composer" (or Single Line variant). Set paragraph direction to Right-to-Left via the RTL alignment icon.
• Kashida justification: only appears in the Paragraph panel dropdown when Middle Eastern composer is active. Choose "Kashida" for justification style to enable the classical Arabic wide-letter-stretching.

Standard-edition workaround:

If you can't reinstall, enable the "World-Ready Composer" via a hidden setting. In Photoshop / Illustrator: Preferences → Type→ check "Middle Eastern Text Engine" (or "Show Indic Options" depending on version). Restart the app. This adds partial MENA support to the standard edition, though some features (like Kashida) still require the full MENA install.

Figma

• Figma respects the browser's bidi algorithm, so Arabic and Hebrew shaping and joining WORK out of the box in a Figma text layer. Kashida does NOT — Figma doesn't expose the OpenType kashida GSUB feature.
• Paragraph direction: Text panel → three dots (…) → Text direction → Right-to-Left. This is per-text-layer.
• Common gotcha: pasted Arabic from a browser sometimes arrives with LTR paragraph direction embedded. If your Arabic renders punctuation-flipped, apply Text direction → RTL manually.

Canva

• RTL support is limited. Basic Arabic and Hebrew text render with correct joining/shaping, but there's no per-text-box RTL paragraph toggle. Punctuation often ends up on the wrong side.
• Workaround: paste a Unicode RLM character (U+200F) at the start of your text. The easiest way is to copy it from Compart's Unicode reference and paste at the start of your text box.

Print / prepress specifics

• PDF export: as long as your source app rendered the Arabic / Hebrew correctly (all joining, punctuation in the right place), the PDF preserves the visual layout — bidi resolution has already happened before export. Print reproduces exactly what you see.
• Font selection matters.Not every font supports Arabic joining or Hebrew punctuation positioning. Adobe Arabic, Adobe Hebrew, SST Arabic, and any Noto Sans/ Serif Arabic or Hebrew variant are safe defaults. A font labeled "Arabic" but without the positional shaping rules will render letters disconnected regardless of your app's bidi settings.
• Kashida in print: only Adobe MENA edition + Middle Eastern composer will apply kashida justification. If you need scribal-style wide letters in a design, either use those tools, or use the Semitic Stretch fonts from /fonts which bake widened letter variants into the font itself (works in any app that renders the font).

Failure #1: A comma typed at the end of an Arabic word appears at the visual beginning of it.

Memory: The word مرحبا, was surprising. — you typed the comma after the Arabic. In an LTR paragraph the comma is a neutral flanked by AL on the left and was(L) on the right. UAX #9 rule N1 resolves it toward the strongest adjacent (AL wins because "was" is separated by a space). The comma joins the RTL run and appears visually LEFT of the Arabic letters — same paragraph reads as The word ,مرحبا was surprising.

Fix:

The word ⁨مرحبا⁩, was surprising.

FSI…PDI seals the Arabic. Now the comma sits outside the isolate, in the LTR paragraph run, and resolves as LTR — staying visually AFTER the Arabic word. In HTML: The word <bdi>مرحبا</bdi>, was surprising.

Failure #2: A closing quote migrates two words to the left.

Memory: He said "مرحبا يا صديقي" and waved. — quoted Arabic phrase inside an English sentence. The closing " is a neutral. Its neighbors are Arabic on the left, space then and (L) on the right. AL wins; quote absorbs into the RTL run and slides across it visually until it exits the RTL region — landing on the far LEFT of the phrase, next to the opening quote. Reads as He said ""مرحبا يا صديقي and waved — both quotes on the same side.

Fix:

He said ⁨"مرحبا يا صديقي"⁩ and waved.

Wrap the ENTIRE quoted phrase — including both quotes — inside FSI…PDI. Inside the isolate, all neutrals resolve within the sealed context; outside, the surrounding English runs untouched. Both quotes end up on the correct sides of the Arabic phrase. Same fix in HTML: He said <bdi>"مرحبا يا صديقي"</bdi> and waved.

Failure #3: A cursor arrow-key that feels "right" moves you further from where you meant to edit.

Memory: The word مرحبا means hello.— cursor sits between the last Arabic letter and the following space. You press → (right-arrow) expecting to move "forward" in the sentence. But right-arrow moves by logical order, one code point forward in memory. In this position, the next code point is the space — which visually sits between the Arabic word and means. So you moved from the RIGHT edge of the Arabic (visually) into the space that comes AFTER the Arabic visually — which is to the RIGHT. Feels correct.

But if the cursor sits BEFORE the first Arabic letter (at the boundary between the opening space and مـ), right-arrow moves logically forward — onto the first Arabic letter — which visually sits at the RIGHT edge of the Arabic word. So cursor jumps a whole word to the RIGHT visually.

Fix:

There isn't a per-string fix; this is a UX-level choice by the OS/editor. Three options:

• Enable "RTL cursor" mode— macOS: System Settings → Keyboard → Text Input → "Move cursor visually in RTL text." Windows: same option in the Language settings. In this mode arrow keys move by VISUAL order regardless of paragraph direction. Right- arrow always moves right on screen.
• Use Home / End for edge-of-line navigation instead of many arrow presses — these are direction-invariant.
• For programmatic cursor placement (test tools, IDE plugins) — always calculate positions from character indices in the STRING, not from screen coordinates. The mental model must be logical order.

The scenario

Text box has default paragraph direction dir="ltr" (or unspecified, which is the same on most Latin-locale systems). User types the Hebrew sentence שלום עולם("Hello world"). Renders visually as שלום עולם — Hebrew reversed, RTL run flowing right-to-left. Cursor sits at the left edge of the visual text (which is where memory-position-end lands in an LTR paragraph).

User presses .. Memory becomes [ש, ל, ו, ם,  , ע, ו, ל, ם, .]. Renders as שלום עולם. — the period appears on the RIGHT of the sentence, and the cursor jumps from the left edge (where it was) to the far right (after the period). Feels catastrophic.

Why the period lands on the wrong side

The period is a neutral (ON). Its neighbors: ם (R) on one side, end-of-paragraph on the other. UAX #9 rule N2 says: neutrals adjacent to the paragraph boundary resolve toward the paragraph direction. Paragraph is LTR here, so the period resolves as L (level 0). The Hebrew run is at level 1 (odd = RTL). Level-0 chars come AFTER level-1 chars visually in an LTR paragraph → period sits to the right of the Hebrew.

From a Hebrew reader's perspective, the sentence "ends" on the LEFT (where reading order stops). Putting the period on the RIGHT is like putting an English period at the beginning of a sentence: .Hello world. Nonsensical.

Fixes, in order of preference

1. Set the container direction to RTL (best)

<input dir="rtl" ...>
<textarea dir="rtl" ...>
<div dir="rtl">...</div>

Now the paragraph is RTL. When the user types a period at the end, UAX #9 rule N2 resolves it toward RTL (the paragraph direction), giving it level 1 — SAME as the Hebrew — so the period sits at the visual LEFT of the sentence, correctly placed as sentence-end for RTL reading. Cursor stays where the user expects.

2. Use dir="auto" if the field accepts both directions

<input dir="auto" ...>
<textarea dir="auto" ...>

Browser infers paragraph direction from the FIRST strong-typed character in the field. Empty field → defaults to the app's locale. Type an English word first → LTR. Type Hebrew or Arabic first → flips to RTL. This is the RIGHT DEFAULT for any user-facing text input in a multilingual app. It costs nothing and prevents the period-jump for every RTL typist.

3. Insert RLM after the punctuation (targeted fix)

שלום עולם.‏   (period followed by U+200F RLM)

If you can't change the container direction (legacy CMS, third-party embed), give the period a strong RTL neighbor. RLM (Right-to-Left Mark, U+200F) is an invisible strong-R character; placing it after the period gives the neutral a strong-R neighbor to its right, so bidi resolution treats the period as RTL and it lands on the visual left. This is the fix documented in W3C's "Inline markup and bidirectional text in HTML".

4. Wrap the whole sentence in RLI…PDI

⁧שלום עולם.⁩   (RLI + text + PDI)

Force an RTL isolate around the sentence with U+2067 RLI (Right-to-Left Isolate) and U+2069PDI. Inside the isolate the "paragraph direction" is RTL regardless of the surrounding container. Use this when you're emitting the string into some other person's paragraph (email body, chat message, log line) and can't predict their container direction. FSI would work too, but RLI is more explicit for content you KNOW is RTL.