Persian typography on the web

What does Persian have that Latin does not?

The core difference is that in Persian the shape of a letter depends on its neighbours. One letter can have up to four forms: isolated, initial, medial and final. The letter beh takes three different shapes on screen in barf, abr and ketab, and in the computer memory it is one code point.

That single sentence is the source of most of the technical trouble in Persian typography. A Latin font has a simple mapping from code point to glyph; a Persian font needs a layer of rules that decides which glyph gets drawn in each position. The next section is about that layer.

Three other differences bear directly on design. First, Persian has no capital letters, so one of the most common hierarchy levers in Latin does not exist here at all, and weight, size and spacing take its place. Second, the dots carry meaning and four letters differ by dots alone, which makes a typeface that draws them small or fused dangerous at small sizes. Third, a large share of the letters drop below the baseline, which is why Persian text looks crowded at the line spacing that suffices for Latin.

And one difference that gets mentioned less and shows up in layout: Persian letter widths vary far more than Latin ones. In the typeface this site uses, the isolated forms of the alphabet range from 209 to 1223 units of a 1000-unit em. Two Persian words with the same number of letters can therefore have completely different widths, and any estimate based on a character count is less precise in Persian than in Latin.

What must a Persian web font carry?

The short answer: the shaping tables. In the OpenType format these are called features and each carries a four-letter tag. The three that are vital for Persian are init, medi and fina: the initial, medial and final forms. Beside them sits rlig, which builds the required ligatures such as lam-alef, and ccmp, which performs the necessary composition and decomposition.

When those tables are missing the browser raises no error. It sets the text, but it does not join the letters, and the result is something any Persian reader recognises as wrong at a glance without being able to say why. That is exactly what happens when you put a Latin typeface on Persian text, or when you take a subset font whose features have been stripped.

The typeface this page is set in carries these features inside its own file: ccmp, init, medi, fina, rlig, calt, locl, plus a few optional ones. We read that from the file itself with the fontTools library rather than from the foundry description. If you are evaluating a typeface, that check is repeatable and takes five minutes.

Three further conditions to check before choosing. First, real weights; a family with only one weight means the browser has to synthesise a bold for emphasis, and in Persian the result is poor. Second, Persian numerals inside the font itself, which is section five of this lesson. Third, a web licence, which on a client project is a legal matter and not a technical detail.

Making the font lighter without breaking it

A Persian typeface is larger than its Latin equivalent, because it holds several glyphs per letter rather than one. The standard way to lighten it is subsetting: removing the parts of the font this site will never need.

The real numbers from this site, read from the files themselves: the full font at regular weight is 42,708 bytes, about 41.7 KB, with 726 glyphs and 652 code points. The subset version is 25,272 bytes, about 24.7 KB, with 599 glyphs and 527 code points. The three weights this site actually loads come to 76,364 bytes together, about 74.6 KB.

Now what was removed, which is where subsetting parts company with guessing. 125 code points went, and 107 of them are accented Latin letters, from A with macron to C with caron: the alphabets of languages this site does not write in. Fifteen more are combining marks. Not one Persian, Arabic or Turkish letter was dropped, and the Turkish-specific letters are all still there, because this site is written in four languages and all of them share one font.

And the trap that wrecks this job more than anything else: subsetting on the basis of "the characters used on the page". The day a writer types a word containing a letter outside that list, that letter renders in a different font. The second trap is worse and specific to the Persian script: if you configure the subsetter so that it does not keep layout features, the init, medi and fina tables go with them and the letters fall apart. In its default mode pyftsubset keeps a set of these features; the danger arrives when someone rewrites that list by hand around Latin needs.

One more setting that matters as much as the size: font-display. With swap the browser shows a fallback first and switches mid-page, and the layout shifts at that moment. With optional, if the font does not arrive in time the fallback stays for that whole visit and no switch happens at all. For Persian, whose letter widths differ sharply from the fallback, that difference in layout shift is large.

Where exactly does the half-space belong?

The half-space is an invisible character, U+200C, that keeps two parts of a word apart without inserting a full space. In standard Persian typography it is correct, and where it goes follows a clear rule.

The rule is this: a half-space is needed only where the last letter of the stem joins to the next one. If the stem ends in one of alef, dal, zal, re, ze, zhe or vav, that letter does not join forward at all and already takes its separate shape, so the solid form is correct from the start and needs no half-space. That is why کارها, بارگذاری and بالاتر are right and must not be split, whereas the standard present-tense form, می‌شود, carries a half-space between the prefix and the rest.

And the mistake that is worse than either: deleting the half-space instead of replacing it. Remove that character and put nothing in its place, and the two words fuse into میشود, which is wrong in standard Persian and hard to read at small sizes as well. If for any reason you do not want an invisible character in your text, put an ordinary space where it was, not nothing.

Let us state this site own position plainly, because the reader sees it on this very page: in our published text we use an ordinary space instead of the half-space, so می شود. That is an editorial choice and not a claim about linguistic correctness; the reason is that an invisible character in text behaves unpredictably in search and in text tooling, and we prefer our text to contain nothing that cannot be seen. If you decide otherwise and keep the half-space, that is entirely defensible. What is defensible under no circumstances is the fused form.

A practical note for typing: on the standard Persian keyboard layout the half-space is shift plus space. If your content team does not know that, your text will be a mixture of all three forms, and that is the worst possible outcome, because your own site search will stop finding the words.

Persian numerals, from a typographic angle

There are three families of digit that resemble one another and are not the same: Latin 0 to 9, Persian numerals, and the Arabic-Indic numerals used in Arabic text. Persian and Arabic-Indic differ in four of the ten shapes and share the rest, and that resemblance is what makes confusing them easy.

Typographically two things matter. First, your font must genuinely contain the Persian numerals; if it does not, the browser borrows them from another font and, in the middle of a sentence, the numbers suddenly acquire a different height and weight. You can see this in thirty seconds: write a Persian number beside your text and look closely.

Second, digit width. In tables and anywhere numbers stack vertically, the digits must share one width or the column falls apart. Most Persian typefaces respect this, though not all, and the way to check is to write several numbers with different digits under one another and see whether their right edge stays a straight line.

This site typeface contains all three families, Latin, Persian and Arabic-Indic, and that is what lets the Persian and the Arabic versions of the site run on one font file while each keeps its own correct numerals.

And one boundary this lesson deliberately does not cross: Persian numerals in forms are a separate and technical problem, not a typographic one. Standard validation patterns do not recognise Persian numerals as digits, and if you make no provision for it, a user who typed their number on a Persian keyboard gets an "invalid number" message. That argument, with its solution, sits in UI design principles.

The Arabic letters that are wrong in Persian

Persian and Arabic share one script and differ in a few letters, and that is why Persian text is full of Arabic letters without anyone noticing. Three matter most: Arabic ي in place of the Persian yeh, Arabic ك in place of the Persian kaf, and ة, which has no place in Persian at all and should be a heh.

Why does it matter, when on screen they look almost identical? Because to a computer they are not identical. Your own site search will not treat a word written with a Persian kaf and the same word written with an Arabic kaf as one, alphabetical sorting breaks, and a search engine sees two different strings. A page whose title is written with an Arabic yeh is not the same page for a query the user typed with a Persian yeh.

It has a typographic effect too: the final form of the Persian yeh and the Arabic yeh differ in most typefaces, because one carries two dots and the other does not. Mixed text looks inconsistent at the ends of words and nobody can say why.

The second family is the hamza forms. In standard Persian, words such as tasir, mabda and jozv are written without a hamza. And adding a hamza over the heh for the ezafe, that is writing خانۀ, is a form that has better replacements in present-day Persian: a space and a yeh, or nothing at all.

The origin of these letters is usually one specific place: the keyboard. Arabic layouts and some default mobile layouts produce Arabic letters. If you have a content team, settle this once in a meeting rather than page by page; the fast path in this lesson carries a command that finds all three families in a single run.

Stretching and fake bold: two things not to do

The first is stretching letters with the tatweel character, U+0640, which turns a word into something like کـــتاب. In calligraphy, elongation is a real and delicate tool with a defined place. In web text it is almost always used to fill a width or make two lines match, and that is exactly where it becomes a problem: the word is no longer the same string, search will not find it, a screen reader reads it differently, and when the text reaches a phone an elongation tuned for desktop becomes meaningless.

The second is fake bold. When a typeface has no bold weight and you ask for weight 700, the browser can thicken the letters itself. For Latin the result is tolerable; for Persian it is not, because machine thickening fills in the counters inside letters and fuses the dots into the body. The right answer is to have a real weight, and if you do not, build emphasis with size or colour rather than with a weight that does not exist.

And a third that is less often recognised as a mistake: justifying text to both margins. In Persian the temptation is stronger, because the Arabic script allows elongation and it looks as though you could justify without ugly gaps. But browsers do not do it by stretching letters, they do it by opening the spaces between words, and the result is the same white rivers. WCAG criterion 1.4.8 says plainly that text should not be justified.

The practical summary of all three: each is an attempt to solve a layout problem with a typographic tool. When a block of text looks wrong, the answer is usually to change the column width or the line spacing, not to manipulate the letters themselves.