Speed Reading in Arabic, Hebrew, Persian and Urdu

Most speed readers do not run right to left at all. The ones that do usually get the direction right and the letters wrong, in a way that is invisible to the person who built them.

ReadKinetic reads Arabic, Persian, Urdu and Hebrew — running the right way round, with the recognition point measured from the right, and without the shaping bug that quietly spoils most attempts at this. Open a book and the script is worked out from the text, so there is nothing to choose.

The mistake almost everyone makes

RSVP readers position a word by its optimal recognition point, and the simplest way to do that is to cut the word at the pivot and hang the two halves off it. In Latin that is invisible. In Arabic it is ruinous.

Arabic, Persian and Urdu letters join: a letter’s shape depends on what sits beside it. Cut a word into pieces and render them separately and the shaper draws initial and final forms where medial ones belong. The word comes out visibly wrong to every native reader — and entirely invisible to a developer who does not read the script, so it ships, and stays shipped.

It is measurable, too. Cutting the Arabic word المكتبة into three pieces makes the glyphs 11.8% wider than the same word drawn whole. That extra width is the letters coming apart.

So the word is moved, not cut

Every Arabic word here is drawn complete, in one piece, and then shifted until its recognition point happens to land on the fixation mark. The shaper only ever sees a whole word, so the letters join exactly as they would in print — and the reader still gets the fixed fixation the format exists to provide.

Finding the pivot inside a joined word turns out to be its own problem. Measuring the letters before it gives the wrong answer for the same reason cutting does — in isolation they take different forms. The usual remedy is a zero-width joiner, and measured here it does nothing at all: the canvas returns an identical width with and without it, putting the pivot 44.1 pixels into المكتبة when the truth is 28.1. So the browser is asked directly, with a range over the pivot inside the complete word.

That measurement, and the code, are written up in full in Arabic letters stop joining the moment you split the word.

Hebrew is the straightforward one

Hebrew runs right to left and its letters do not join, so it keeps the full pivot treatment with the geometry mirrored: the first letter of a word is its rightmost, and everything before the recognition point hangs off the right-hand edge instead of the left.

That is why Hebrew was the first of these to work. It needs the direction handled honestly and nothing else.

A quotation is not a language

Deciding what a book is written in by whether a script appears at all is a trap: one Arabic word in an English book would turn the whole thing round, and one Chinese character would change how every word in it is split. So the question asked is how much of the writing is in that script, not whether any of it is.

An Arabic book full of English technical terms stays Arabic; an English book quoting كتاب stays English. This is the normal case rather than an edge case — a technical book in Arabic is full of English, and a book about linguistics in English quotes everything.

The interface stays left to right

Deliberately. Mirroring an entire application multiplies the work and the number of places a bug can hide, and most readers of these scripts use left-to-right interfaces every day. What has to be right is the book.

The pacing already worked

Anticipatory pacing — easing the pace down just before a difficult word — needed no work for any of these languages, and that is worth explaining.

Difficulty is decided by counting words in the book you are reading, not by consulting a shipped English frequency list. Zipf’s law holds in every natural language, so the common words sink to the bottom on their own in Arabic exactly as they do in English.

A shipped word list would have had to be built, downloaded and maintained for each language, and would still have been wrong about a proper noun the book had already taught you. Counting in-book cost nothing and works everywhere, which is an unusual thing to be able to say about a feature meeting a new script.

Everything else works the same

EPUB and PDF both import as normal, chapters and marks and find all work, and nothing is uploaded — the file is parsed in your browser and stays on your device.

The PDF page mapping is indifferent to direction, because a PDF stores its text in logical order whichever way it is drawn. Arabic, Hebrew, and pages opening on a Latin term inside an Arabic book are all covered by tests.

One honest caveat

All of this has been verified by measurement — glyph widths, pivot positions, page mapping. That is not the same as being verified by somebody who reads the script, and I want to be plain about which one I have done.

If you read Arabic, Persian, Urdu or Hebrew and something looks wrong to you, it probably is, and I would genuinely like to know.

Common questions

Which right-to-left languages does ReadKinetic support? Arabic, Persian (Farsi), Urdu and Hebrew. The script is detected from the book itself, so there is nothing to set — open the file and it runs the right way round.

Do Arabic letters join properly in an RSVP speed reader? In ReadKinetic, yes, and this is the part most implementations get wrong. Arabic, Persian and Urdu letters change shape according to their neighbours. A speed reader that cuts a word into pieces to position it renders initial and final letterforms where medial ones belong — obviously wrong to any reader of the script, and completely invisible to a developer who does not read it. ReadKinetic never cuts these words. It draws each one whole and moves it into position instead.

Do you still get the optimal recognition point in Arabic? Yes. The word is drawn whole and then shifted until its recognition point lands on the fixation mark, rather than being split there. Measured in the running app, the pivot lands on the anchor to within a hundredth of a pixel — the same fixation a Latin or Hebrew reader gets, with the shaper only ever seeing a complete word.

How is the pivot letter highlighted without splitting the word? The same word is drawn a second time and clipped to the pivot’s own column. Identical glyphs, shaped once each, with the top copy showing through only where the pivot is. Colouring part of the text would mean splitting the text, which is the one thing that cannot be done in a joining script.

Is Hebrew handled differently from Arabic? Yes, because Hebrew runs right to left but its letters do not join. That makes it the straightforward case: it keeps the ordinary pivot treatment with the geometry mirrored, so the first letter of a word sits rightmost and the recognition point is measured from the right.

What about a book that mixes Arabic and English? That is the normal case in any technical book, and it works. The script is decided by how much of the writing is in it rather than by whether it appears at all — so an Arabic book full of English terms stays Arabic, and an English book that quotes one Arabic word stays English and keeps running left to right.

Is the interface in Arabic or Hebrew too? No, and that is deliberate. The book runs right to left; the interface stays left to right. Mirroring an entire application multiplies the work and the number of places a bug can hide, for little gain — most readers of these scripts use left-to-right interfaces all day. It is the text that has to be right.

Does the anticipatory pacing work in Arabic and Hebrew? Fully, and with no extra work at all. Anticipatory pacing eases the pace before a difficult word, and it decides which words are difficult by counting them in the book you are reading rather than from a shipped English word list. Zipf’s law holds in every language, so the common words sink to the bottom on their own in Arabic exactly as they do in English.

Which fonts does it use for Arabic and Hebrew? A stack the device already has — Geeza Pro or Noto Naskh Arabic for the Arabic family, Arial Hebrew or Noto Sans Hebrew for Hebrew. Naskh is preferred for Arabic because it is what books are actually set in. Nothing is downloaded.

Can it read Arabic PDFs as their real pages? The page mapping is indifferent to direction — a PDF stores its text in logical order whichever way it is drawn, and the alignment matches sequences of words. Arabic, Hebrew, and pages opening on a Latin term inside an Arabic book are all covered by tests. A scanned Arabic PDF has no text in it and will be refused, as any scan is.

Is my Arabic or Hebrew book uploaded anywhere? No. Every file is parsed and rendered inside your own browser and stored on your device. There is no server to upload to and no account to make.