Fix RTL rendering for Hebrew and Arabic scripts

[Jonathan-Asher]

Reading a Hebrew script in the teleprompter is currently not usable. There is partial RTL support already (TextDirection.swift, the layoutDirection flip in WordFlowLayout), but it breaks down in four independent ways.

1. Word spacing collapses entirely

WordFlowLayout spaces words by appending a trailing space to each Text (Text(item.word + " ")). Text layout trims trailing whitespace when measuring, so in an RTL line every gap measures zero and the whole line renders as one unbroken string:

before:  ברוכיםהבאיםלטקסטרים!זהוהטלפרומפטרהאישישלך
after:   ברוכים הבאים לטקסטרים! זהו הטלפרומפטר האישי שלך

Words are now spaced by the enclosing HStack instead, which is direction-agnostic. LTR output is unchanged.

2. Embedded LTR runs render reversed

Flipping layoutDirection reverses every word box on the line, including consecutive Latin words that should stay in reading order among themselves:

For the input ...והיא עובדת מצוין עם Claude Code על מק, the embedded Latin pair renders as Code Claude before this change and Claude Code after it.

Each line is now reordered with the Unicode Bidirectional Algorithm's L2 reordering rule applied at word granularity (bidiVisualOrder), so only the runs that need reversing are reversed. Each word is additionally wrapped in a directional isolate (RLI/LRI…PDI) so its own trailing punctuation and bracket mirroring resolve against the run it belongs to rather than against the ambient layout direction — otherwise שלום, puts the comma on the wrong side.

Numbers are treated as LTR, matching UBA rule I1 (European numbers always take an even embedding level), so 1.6.3 inside Hebrew text keeps its digits in order while still sitting at the correct point in the RTL flow.

3. The editor loses its direction on every keystroke

HighlightingTextEditor.updateWritingDirection sets the base writing direction, but applyHighlighting then calls textStorage.setAttributes over the full range with only .font and .foregroundColor — wiping the paragraph style that carries the direction. In textDidChange the two run in that exact order, so Hebrew snaps back to left-aligned as soon as you type. The paragraph style is now part of the default attribute set and of typingAttributes/defaultParagraphStyle, so it survives the reset.

4. The browser teleprompter treats every Hebrew word as a stage cue

isAnnotation and letterCount in the served HTML test against a hardcoded range list:

/[a-zA-Z0-9À-ɏЀ-ӿ　-鿿가-힯]/

Hebrew, Arabic, Greek, Thai, Devanagari and others are absent, so every word in those scripts is classified as emoji-only: rendered dim and italic in the cue colour, skipped by the next-word scan, and never scrolled to. The browser view is completely non-functional for these languages. Both helpers now use \p{L}/\p{N}, which matches the native side's isLetter || isNumber, and the text container gets a dir attribute so the browser's own bidi engine orders each line.

Base direction heuristic

textBaseDirection uses first-strong detection, which misreads a script opening with a Latin product name or speaker label — a single leading Textream lays an entire Hebrew page out left-to-right. Added dominantBaseDirection, which picks whichever script has more letters; scripts are read whole, so the dominant script is the better signal at page level. textBaseDirection is left in place.

Also added dir="auto" to the director page's script panes.

Verification

Rendered WordFlowLayout directly through ImageRenderer across four fixtures — pure Hebrew, Hebrew with embedded English and numbers, Hebrew punctuation, and an English control. All three Hebrew cases are correct after the change; the English control is pixel-identical before and after. The browser-side classification and direction helpers were checked against Hebrew, Arabic, CJK, Greek, Latin, digit-only, emoji and bracketed-cue inputs.

Built and running locally on macOS 15 (Apple Silicon).

🤖 Generated with Claude Code