In right-to-left text, caret motion runs opposite visual advance

What it is

In right-to-left (RTL) writing such as Arabic and Hebrew, new characters appear to the left of the caret and the line grows from the right edge. Visual “writing forward” is toward the left. If an editor still draws “forward” as the caret moving right, Latin-style, users see the caret run against the ink. This is caret versus ink growth in a single-direction paragraph, not yet the mixed-direction boundary.

Why it happens

The logical string is stored in memory order (earlier letters have smaller indices); an RTL run is painted right-to-left. The caret sits at logical index i, the next stroke inserts at i, and visually that glyph appears to the left of the current one. The caret's screen x therefore decreases while typing. IME, backspace, and selection also walk the logical string: backspace deletes the logical previous character, which in RTL is often the glyph to the visual right—looking to a Latin-only viewer like “deleting what came after.” Platform text engines (Core Text, HarfBuzz plus the bidirectional algorithm) perform this transform; homemade layout that only does x++ breaks RTL immediately.

Studying it

Ask RTL-native typists to type, backspace, and move with arrow keys in a purely Arabic or Hebrew paragraph, and record whether expected caret motion matches the implementation. Compare a visualized “logical caret” (showing indices) with a purely visual caret. Keep English out of the materials so the task does not become a mixed paragraph. Eye tracking can show whether they hunt for the insertion point at the visual right (the line start). Repeat the same passage under right alignment and justified alignment to confirm alignment is not drawing the caret back into Latin-style rightward growth.

Where it stops holding

Pure LTR paragraphs do not have this issue. Vertical Chinese “forward” is down, neither left nor right, and must not reuse RTL rules. Digits and Latin embedded in RTL reverse locally—that is mixed-direction. A page that lays out LTR while the content is RTL (no dir set) paints the whole run backwards; a correct caret cannot rescue reading.

Applying it

• Match field language or dir to the content so the engine uses an RTL caret, rather than forcing Arabic into an LTR container.
• Hit-test the caret against visual clusters, not a linear x of logical indices.
• In tutorial art, draw the RTL line start on the right.
• Verify by typing three letters at the end of pure RTL: the caret should step left and new glyphs should appear leftmost. A caret stepping right means direction is wrong.

Related

• Same group: C6.30.2 In mixed-direction text, the caret at a direction switch needs extra rules to decide logical order · C6.30.3 Visual caret location and the logical insertion point may not correspond intuitively in bidirectional text · C6.30.4 Left/right arrow semantics must be remapped to text direction rather than assumed fixed
• Adjacent: C6.13 Text selection and caret placement · C6.18 Regional keyboard layout differences
• Search: RTL caret · visual order · Arabic editing