Arabic font fallback and line height ¶

The layout mirrors correctly, the direction attribute is set, and the Arabic still looks wrong: letters that should join stand apart, vowel marks are sliced off at the top of the line, and a product name in Latin script inside an Arabic sentence renders noticeably larger than the text around it.

Direction is a layout property. What the text looks like is a typography property, and it is decided by which font supplies each glyph and how much vertical room the line box gives it.

Root cause: font selection is per character, and Latin defaults are tight ¶

A browser resolves font-family per character, not per element. It walks the list and uses the first family that contains a glyph for that character. A stack naming a Latin-only family first and a generic fallback last therefore takes Latin glyphs from the intended font and Arabic glyphs from whatever the platform provides.

That platform font may be fine or may lack the shaping tables that join Arabic letters into words, which produces the disconnected look. It will almost certainly have different proportions from the Latin family beside it, which is why mixed runs appear to change size mid-sentence.

The vertical problem is separate and just as common. Arabic script places marks above and below the baseline, and fully vocalised text stacks several. A line height tuned for Latin — or worse, set in a fixed pixel value — gives no room for them, so marks are clipped by the line box above.

A third, quieter issue is numerals. The digits rendered for a locale depend on the numbering system, and some Arabic locale tags select Eastern Arabic numerals. That is correct for those locales and surprising when it appears unintentionally, usually because a tag such as ar-EG-u-nu-arab was copied from an example.

Minimal reproducible example ¶

/* Latin-first stack: Arabic glyphs come from wherever */
body {
  font-family: 'Inter', system-ui, sans-serif;
  line-height: 1.4;          /* comfortable for Latin, too tight for marks */
}

<p dir="rtl" lang="ar">مَرْحَبًا بِكَ في Acme</p>
<!-- marks clipped, Latin "Acme" larger than the Arabic around it -->

The fix: name the Arabic family, scope it, and give the line room ¶

@font-face {
  font-family: 'Noto Sans Arabic';
  src: url('/fonts/noto-sans-arabic.woff2') format('woff2');
  unicode-range: U+0600-06FF, U+0750-077F, U+08A0-08FF, U+FB50-FDFF, U+FE70-FEFF;
  font-display: swap;
}

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+2000-206F;
  font-display: swap;
}

:root { --font-stack: 'Inter', 'Noto Sans Arabic', system-ui, sans-serif; }

body {
  font-family: var(--font-stack);
  line-height: 1.75;         /* unitless, so it scales with font-size */
}

[lang="ar"], [dir="rtl"] {
  line-height: 1.9;          /* extra room for stacked marks */
}

Two mechanisms do the work. unicode-range tells the browser which characters each family is responsible for, so the Latin font is never asked for an Arabic glyph and the Arabic font is downloaded only when Arabic characters are on the page. A unitless line height scales with the font size instead of pinning a box that marks then overflow.

Matching the two fonts to each other ¶

Even with both families loading correctly, a mixed line can look uneven, because the two typefaces were designed independently.

The property that matters most is the relationship between the Arabic and Latin sizes. Arabic letterforms are typically drawn smaller relative to their em box than Latin ones, so an Arabic family set at the same font-size often looks smaller than the Latin beside it. Font families designed as pairs — a Latin and an Arabic released together — solve this by construction, and where a pair is not available, a small font-size-adjust or a per-script size step closes most of the gap.

/* If the Arabic reads small next to the Latin at the same size */
:lang(ar) { font-size-adjust: 0.52; }

The second property is weight. Not every Arabic family ships the same weights as its Latin counterpart, and a missing weight is synthesised by the browser — a smeared approximation that looks noticeably worse in a connected script than it does in Latin. Restricting the interface to weights both families genuinely have is usually better than accepting synthesis.

Loading two scripts without paying for both ¶

Adding a second script family doubles the potential font payload, and unicode-range is what stops every reader paying for both.

The mechanism is precise: a browser downloads a font file only when a character in its declared range actually appears on the page. An English page therefore fetches the Latin file and never touches the Arabic one, and an Arabic page does the reverse. Declaring the ranges accurately is what makes that work — a family declared with no range is a candidate for every character, so it downloads everywhere.

Subsetting compounds the saving and introduces the risk mentioned above. A subset built by character coverage is safe; one built by an aggressive optimiser that strips layout tables produces a file that contains the glyphs and cannot join them. Where a build pipeline subsets automatically, it is worth rendering a sample of connected text from the output as a build check rather than trusting the tool.

The third lever is font-display. A connected script rendered in a fallback font during load looks substantially more wrong than Latin does — the letters do not join, so the fallback period is visibly broken rather than merely different. Using swap keeps text readable throughout, and preloading the family for the current locale removes most of the window entirely.

Preloading is the one decision that depends on the locale being known before the stylesheet resolves, which it is: the resolved locale is in the URL, so the document can preload exactly the family that page will use and nothing else.

Verification ¶

Automated checks catch the mechanical failures; the rest needs eyes.

test('Arabic text is rendered by the Arabic family', async () => {
  await page.goto('/ar/pricing');
  const font = await page.evaluate(() => {
    const el = document.querySelector('[lang="ar"], p')!;
    return getComputedStyle(el).fontFamily;
  });
  expect(font).toMatch(/Noto Sans Arabic/);
});

test('vocalised text is not clipped', async () => {
  // A line box shorter than the rendered glyphs means marks are cut.
  const clipped = await page.$$eval('p[lang="ar"]', (els) =>
    els.filter((el) => el.scrollHeight > el.clientHeight + 1).length);
  expect(clipped).toBe(0);
});

Beyond that, a screenshot comparison across a fully vocalised sample and a mixed Arabic-Latin sentence is the check that actually finds proportion problems — the sweep described in screenshot diffing RTL layouts in CI.

When to escalate ¶

If letters still do not join, the font file may be a subset without shaping tables. Subsetting tools can strip the tables that make a connected script work, and the fix is to subset by character range rather than by aggressive optimisation.

If the correct font loads and the text still looks wrong, check for a font-synthesis effect: a missing weight or italic is being approximated. Arabic has no italic tradition, so a synthesised oblique is always wrong there.

If numerals render in an unexpected system, inspect the locale tag reaching the formatter — a -u-nu- extension changes the digits, and it is inherited from whatever tag was passed rather than from the direction.

FAQ ¶

Related ¶

• RTL & Bidirectional Layout Engineering — the direction model this typography sits on.
• RTL flexbox and grid order bugs — the layout failures that look similar and are not.
• Screenshot diffing RTL layouts in CI — catching proportion regressions automatically.
• Text expansion clipping in fixed-width buttons — the horizontal counterpart of a clipped line box.

Part of RTL & Bidirectional Layout Engineering.