Phone numbers that swap halves

A user types this into the phone field of an Urdu visiting card:

0300 1234567

The card shows 1234567 0300.

Nothing changed the text. In a right-to-left paragraph the Unicode bidi algorithm sees the space as a break between two separate number runs, and it lays those runs out right to left. In Pakistan phone numbers are usually written with a space (0300 1234567, +92 300 1234567), and account numbers come in groups too, so this shows up on cards, invoices and fee challans.

The fix is to wrap every multi-part number in a left-to-right isolate (U+2066 LRI … U+2069 PDI) when we draw it:

private const val DIGIT = "[0-9\u06F0-\u06F9\u0660-\u0669]"
/** A number with at least one space, dash, slash, dot, colon or comma between digit groups. */
private val spacedNumber = Regex("\\+?$DIGIT+(?:[ \\-/.:,]$DIGIT+)+")

fun isolateNumbers(text: String): String =
    if (!hasUrdu(text)) text
    else spacedNumber.replace(text) { "\u2066${it.value}\u2069" }

Three details mattered:

• Only at render time. The saved text is never changed, so copying or editing the field gives back exactly what the user typed.
• Urdu and Arabic-Indic digits too. An Urdu keyboard can type ۰۳۰۰ instead of 0300.
• Don't isolate twice. Our real version skips parts that are already inside an isolate, and tests check that English text and single numbers are left alone.

"1800" became "180 0"

On a zoomed-in invoice preview, a price of 1800 could show a gap: 180 0. We set the text paint to linear text and subpixel positioning, and we measure with the same paint and the same isolation we draw with. If you measure with one paint and draw with another, numbers will drift.

Tables have to be mirrored, not just right-aligned

An Urdu invoice isn't an English invoice with right-aligned text. The first column (item name) goes on the right, and the totals go on the left. We draw invoices, result cards and exam date sheets as their mirror image in Urdu. A device test checks that the first column really is the rightmost one in Urdu, and the leftmost in English as a control.

Nastaliq is tall, so prices floated

Nastaliq lines are much taller than Latin lines, because the letters slope and stack. On a menu, prices were drawn from the top of each dish line, so next to a tall Urdu dish name the price hung near the top of the row. We now centre the price on the dish line.

The same height problem shows up on the web. Our site uses line-height: 2.4 for Urdu body text and about 2 for Urdu headings, against 1.6 for English. Below that, the dots and tails of one line run into the next.

Bottom sheets forgot the direction

The app was in Urdu (right to left), but bottom sheets opened left to right. In Compose a bottom sheet opens in its own window, and it doesn't take the layout direction from the screen behind it. We set the direction again inside our shared sheet component, and that fixed six sheets at once.

The 260 KB font on English pages

Our website has an "اردو" button on every English page. That one word made every English page download Noto Nastaliq Urdu, about 260 KB, and Lighthouse put it on the first-paint path. A prompt page scored 65 on mobile performance, with a 6-second LCP.

The fix was one CSS rule: on English pages, Urdu links use the phone's own Arabic-script font.

html:not([lang="ur"]) a[lang="ur"] {
  font-family: system-ui, "Noto Naskh Arabic", "Noto Sans Arabic", sans-serif;
  line-height: inherit;
}

Urdu pages still load Nastaliq. The same page then scored 100 in a local Lighthouse run.

What I'd check first in any Urdu or Arabic app

1. Type a phone number with a space into an RTL field and look at it.
2. Draw prices on a zoomed preview and look for gaps.
3. Open every bottom sheet and dialog in RTL.
4. Put a long Nastaliq line next to anything that should line up with it.
5. See which fonts your English pages download.

You can see the Urdu pages at app.sitey.pk/ur/. If you've hit other RTL bugs, I'd like to hear about them in the comments.

This post was written with AI assistance, from our own code and commit history.