PandaText / Guides / How Arabic and English share one line
How Arabic and English share one line
Arabic and English can share one line. The Unicode Bidirectional Algorithm splits the line into runs by direction and orders them, and the letters inside an Arabic run go right to left. In an English sentence with an Arabic name, the Arabic appears on screen in the opposite order from the characters in the string.
We put the same mixed text on five surfaces, each in its system font: an iPhone, an Android phone, and Chrome, Safari and Firefox on a Mac. All five ordered the runs the same way and broke the lines on the same words. They still differed in three visible ways.
1. Each surface draws the Arabic in its own font
The English sentence with two Arabic phrases broke after the same words everywhere. The Arabic itself looks different on each surface. The iPhone, Chrome and Safari drew it in the same Apple Arabic font, Android in its own, and Firefox in a narrower one: the whole sentence measured 597.0 px unwrapped in Firefox and 622.9 px in Chrome and Safari.
This line had room to spare. In a tighter line, a gap that size moves a word, as it did for the Thai and Arabic sentences in the iOS and Android test.
2. Android makes lines with Arabic taller
The same three lines were 61.0 to 64.0 tall on the iPhone and in the browsers, and 78.3 dp on Android, about a quarter taller. Android makes every line tall enough for the fallback font it uses for Arabic, through a TextView setting that is on by default; with it off, Arabic lines were as tall as English ones in our earlier test.
A note, a comment thread or a chat that mixes Arabic and English is therefore longer on Android, and anything placed below or beside it moves.
3. Letter-spacing pulls Arabic apart on iPhone and in Safari
Arabic letters join, so spacing them apart breaks the script. With 3 points of letter-spacing, the iPhone and Safari spread the letters anyway, and the sentence needed two lines. Android, Chrome and Firefox kept the letters joined and the sentence on one line. Unwrapped, it measured 374.2 px in Safari, 275.2 px in Chrome and 230.3 px in Firefox.
Chrome stopped applying letter-spacing to Arabic and other cursive scripts in version 149. A style with letter-spacing, often used for headings and labels, therefore looks right in one place and broken in another.
Selection has a visual range and a logical range
Selecting from inside “invoice” to the middle of the Arabic words gives one range in the string but two highlighted pieces on screen, because the Arabic run is drawn in the opposite order. All five surfaces painted it the same way here.
The range you store, copy and send to the IME is the logical one. Mapping it to the highlight, and a tap back to an offset, depends on the line's bidi levels and on the glyph positions. With different fonts on each platform, those positions differ, so shared measurement has to include these rectangles.
Marks you can put in the string
When a product controls the string, Unicode marks can pin a direction: an embedding, an isolate or an override. They help a short label with a known pattern, such as an Arabic name followed by a Latin number. They are a poor fix for a document the reader edits, because readers do not type marks. The file should store the characters the reader typed, and the engine should resolve directions from them on each layout.
One layout for mixed lines
PandaText places the Arabic and English runs in one layout pass, with the same fonts and widths on every platform, so a mixed line breaks in the same place everywhere. Here is the mixed sentence from the first test in PandaText on both phones, on the Mac and in three browsers. Each shows three lines, broken after “2026-114” and “at”, with the Arabic words in the same order.
How we tested
Two small apps showed the text in UITextView on an iPhone 18 Pro simulator (iOS 27.0) and TextView on a Pixel 10 Pro emulator (Android 17), and a test page showed it in Chrome 156, Safari 27.0.1 and Firefox 159 on a Retina Mac (macOS 27.0.1), in October 2026. Each used its system font at 17 pt, dp or px in a box 300 wide. Letter-spacing was 3 points, 3 px, or 3/17 em on Android. Each surface reported its own line breaks and height.
Check a mixed-direction line
- Use a real mix. Put an Arabic phrase in the middle of an English sentence, with a number beside the Arabic.
- Compare fonts and heights. Open it on every platform you ship and compare the Arabic glyphs, the line breaks and the paragraph height.
- Copy the selection. Select from the English into the Arabic and paste into a plain text field. The characters should come back in the order they were typed.
- Check your styles. Apply any letter-spacing your headings or labels use to Arabic text, and look for letters pulled apart.
Questions
Does setting the paragraph to right-to-left fix mixed lines?
It changes the base direction, which is right for an Arabic paragraph. An English paragraph with an Arabic phrase needs a left-to-right base and a right-to-left run, and one alignment flag cannot say both.
Should the editor store the visual order?
No. Store the logical string the reader typed. Visual order is a layout result, and storing it breaks search, paste and the next layout at a different width.
Sources
- Unicode UAX #9: Unicode Bidirectional Algorithm
- Pretext: Engine Follow-ups
- Android Developers: TextView.setFallbackLineSpacing
- WebKit bug 281204: combining marks with letter-spacing
Related guides
Why the same text wraps differently on iOS and Android
One sentence on an iPhone and an Android phone, same size and width. The system font, emoji and line height each changed the result.
How to measure text the same way on every platform
Canvas measureText() was off from the page by up to 50 px in Chrome and Firefox. Why one engine should return the width, line breaks and carets.