RTL DTP for Hebrew and Arabic: Fix Mirrored Layouts

A Hebrew time stamp can look correct in Word and turn into a different sequence after someone pastes it into InDesign. A real Adobe Community user reported seeing 58:12 display as 21:85 in a Hebrew text context after pasting. That report describes one person’s case, not a universal InDesign defect, but it shows why RTL DTP needs more than a right-aligned paragraph.

Fixing a mirrored layout means separating several controls that often get mixed together: paragraph direction, page binding, character shaping, and the handling of embedded left-to-right text. Change the wrong one and a page may look closer while its reading order, punctuation, or navigation gets worse.

This guide explains what happens under the hood, how to set up an RTL document in InDesign or Word, and how to test mixed Hebrew, Arabic, and Latin text before delivery.

What RTL DTP means, and what it doesn’t¶

Right-to-left DTP is the process of laying out text and pages for languages whose scripts generally read from right to left. Hebrew and Arabic are common examples. The term describes a document workflow, not a command to reverse every line or mirror every design element.

An RTL paragraph has a base direction that guides its reading order and alignment. Inside that paragraph, a Latin company name or a number can still read left to right. A right-to-left publication may also use right-side binding and a different page sequence from a Roman-language publication. Those settings are related, but they aren’t interchangeable.

Unicode stores characters in logical order: the sequence in which a person reads and edits the text. A display engine uses the Unicode Bidirectional Algorithm to decide how characters should appear visually when scripts with different directions share a line. Unicode describes logical order as the prescribed memory representation order in Unicode Standard Annex #9.

“The Unicode Standard prescribes a memory representation order known as logical order.”
— Unicode Standard Annex #9

That distinction matters during editing, copying, searching, and export. A paragraph can look visually reversed in a particular application while its characters remain in the correct logical sequence. Manually reversing those characters isn’t a general RTL repair: it can break search, copy-and-paste, screen-reader output, and display in other applications.

The word “mirrored” also causes confusion. A Hebrew or Arabic page isn’t automatically a mirror image of an English page. The binding edge, page sequence, alignment, and location of interface elements may change, but logos, photographs, diagrams, and numbers shouldn’t be flipped without a design reason.

A useful starting checklist separates the controls:

Before changing a setting, identify what looks wrong. If a whole line aligns to the wrong side, check paragraph direction. If a book opens from the wrong edge, check binding. If only a date or parenthesis moves, inspect the mixed-direction run. That diagnosis saves time and avoids fixes that only hide the symptom.

For a closer look at common language-specific issues, see Arabic RTL layout: fixing direction and formatting issues.

How bidirectional text produces surprising layouts¶

A Hebrew or Arabic paragraph that contains Latin words or digits is bidirectional. Its characters don’t all follow one direction, and the display engine doesn’t simply read the line from one edge to the other as a single unit.

The Unicode Bidirectional Algorithm assigns character types and applies rules to determine visual ordering. Strong characters, such as letters from a script, help establish direction. Numbers usually have weak directional types. Spaces and punctuation can be neutral, which means their visual position depends on paragraph direction and surrounding characters rather than a direction of their own. The Unicode algorithm and Microsoft’s explanation of text directionality describe these properties.

Consider an Arabic paragraph containing a Latin product name, a colon, and a time. The letters in the Arabic words establish RTL runs. The Latin name forms an LTR run. The colon may be neutral, and the digits have their own bidi behavior. The application resolves the sequence from those character properties and the paragraph’s context. If the result doesn’t match the intended reading, flipping the whole line is the wrong first move.

The first strong character can influence reading direction and alignment when an application uses contextual direction. Microsoft documents that a first strong LTR character can produce LTR reading and left alignment, while a first strong RTL character can produce RTL reading and right alignment. Text containing only neutral characters follows the paragraph direction until a strong character appears. Explicitly setting paragraph direction gives a layout more predictable behavior than relying on whichever character happens to come first.

Neutral punctuation explains why a colon, comma, bracket, or space can seem to jump. A space doesn’t “belong” to Hebrew, Arabic, or English on its own. The surrounding runs and paragraph context affect its placement. A bracketed Latin abbreviation in an RTL sentence can therefore need a deliberate review even when the letters themselves are correct.

Microsoft Learn lists two directional marks that can help with a short LTR run in RTL context: LRM (U+200E) and RLM (U+200F). Its example uses an LRM before a number and an RLM after it to mark the number as an LTR run. A mark can help resolve a specific context problem, but adding invisible controls by habit makes a document harder to debug. Use one only when a test shows that the surrounding context doesn’t produce the intended result.

Unicode also defines directional isolates: LRI (U+2066), RLI (U+2067), FSI (U+2068), and PDI (U+2069). An isolate marks a directional run without letting the enclosed text affect the ordering outside it. Unicode encourages isolates rather than embeddings in new documents once the target platform’s support is known. For web pages, the standard directs authors to use HTML and CSS mechanisms rather than explicit bidi formatting characters.

“The direction of the text can be changed from within a Microsoft 365 program by choosing the Right-to-left paragraph button in the Paragraph group on the Home tab (this only appears if you have a right-to-left language enabled).”
— Microsoft Support

The practical lesson is to set the paragraph’s base direction first, then isolate or mark only the runs that need help. Don’t scatter invisible marks across a whole document as a substitute for checking the text structure. Keep a clean source copy so an editor can compare the actual logical sequence with the visual result.

Set up the document before adjusting individual lines¶

A predictable RTL layout starts with document-level settings. Paragraph direction, page binding, and a script-capable composer solve different problems; setting one doesn’t silently set the others.

InDesign: separate story direction from page binding¶

Adobe’s Middle Eastern scripting guide documents a right-to-left page-binding option through the document’s pageBinding property. The same guide exposes storyDirection for the direction of an existing story and documents changing text frames to the Adobe World-Ready Composer. These controls address different parts of the layout.

“In a Roman publication, the binding of documents is always on the left. Conversely, in an Arabic or Hebrew publication, binding is on the right.”
— Adobe InDesign Server Middle Eastern Scripting Guide

The quote describes conventional publication binding. A right-side binding changes how a publication opens and how pages relate to the spine. It doesn’t reverse the letters in text frames. Conversely, setting a story’s direction to RTL doesn’t change which edge a book binds on.

For an InDesign document, check these settings independently:

1. Set page binding for the publication. Choose a right-to-left binding when the publication’s intended format calls for it.
2. Set story or paragraph direction. Confirm that the text itself uses the intended RTL direction rather than relying on alignment alone.
3. Use an appropriate composer. Adobe documents separate Roman and Middle Eastern composers and provides changeComposer() to change text frames to the Adobe World-Ready Composer.
4. Review each text frame. A page can have correct binding while an individual story remains LTR, or the reverse.
5. Check special punctuation. Adobe lists Arabic comma, semicolon, question mark, and kashida, along with Hebrew geresh, gershayim, and maqaf. Those characters can be distinguished from generic Latin punctuation during QA.

A composer handles how text is composed; it doesn’t decide the intended page sequence. A right-to-left story direction controls the text flow; it doesn’t set the binding edge. Treating each setting as a separate checkpoint makes it easier to find the source of a problem.

Word: enable the language, then set the paragraph¶

Microsoft distinguishes the Office display language from the direction used in a document’s editing area. Changing the display language can reverse Office menus, but that change alone doesn’t enable RTL text entry. Microsoft’s Office guidance says composing in an RTL language requires enabling the relevant Windows keyboard language.

In Microsoft 365, the RTL paragraph-direction button appears when an RTL language is enabled. Select the relevant text or place the cursor in the paragraph, then use the direction control in the Paragraph group on the Home tab. Microsoft says the controls can set text, bullets, and numbering to right-to-left.

That distinction helps diagnose a common setup problem: the menus appear in a right-to-left language, but typing or paragraph controls still behave unexpectedly. The display language changes the application’s interface. The editing direction and keyboard language affect document work.

For bullets and numbered lists, check the list as well as the paragraph. A list marker can sit on the wrong side even when the text itself is RTL. Microsoft documents setting text, bullets, and numbering through the RTL editing controls, so inspect all three instead of judging direction from the first line alone.

Page order and reading order¶

A publication can bind on the right while its source file, page thumbnails, or exported PDF still needs an explicit page-order check. A right-side binding convention doesn’t guarantee that every application will present pages in the order the reader expects. Verify the exported file by opening it and checking the cover, first spread, middle spreads, and final page.

Don’t rearrange every page by dragging thumbnails until the cover looks right. That can produce a file whose visual opening seems correct but whose page sequence, spreads, or navigation is wrong. Confirm how the layout application interprets binding, spreads, and export order before changing individual pages.

Fix mixed Hebrew, Arabic, English, and numbers¶

Mixed-direction strings cause a large share of “mirrored text” reports because a short LTR run can sit inside an otherwise RTL paragraph. The fix depends on whether the problem affects the whole paragraph, a particular run, or only a neutral character such as punctuation.

Start with the smallest affected unit. If the whole paragraph reads in the wrong direction, set its base direction. If the paragraph is correct but a Latin name, number, or reference moves, inspect that run. If only a colon or parenthesis appears on the unexpected side, review the surrounding strong characters and punctuation type.

Use this sequence when a line looks wrong:

1. Check the text’s logical order. Confirm that the source characters appear in the sequence a reader should copy, search, and edit.
2. Set paragraph direction explicitly. Don’t rely only on right alignment or on the first character in the line.
3. Identify each direction change. Mark where RTL text gives way to Latin text, digits, or a mixed-language label.
4. Inspect neutral punctuation. Look at spaces, commas, colons, brackets, and quotation marks next to direction changes.
5. Test an appropriate mark or isolate if needed. Use directional controls deliberately, and confirm that the target application supports the chosen method.
6. Check the result in the exported file. A line that looks right in the editing view can behave differently after export or when opened in another application.

A time or reference number can be especially confusing because numbers have weak bidi types. One Adobe Community user described a Hebrew and English InDesign e-book where a number pasted from Word appeared as 21:85 instead of 58:12. The forum post, dated March 3, 2025, is a useful example of the kind of symptom to investigate, not evidence that every InDesign file has the same bug.

When a number appears in the wrong visual order, first compare the copied text with the rendered line. If the logical sequence is intact, check paragraph direction and surrounding punctuation. Microsoft’s LRM/RLM example can help mark a number as an LTR run in an RTL context. Unicode isolates can also keep a marked run from affecting text around it when the target software supports them.

Language-specific punctuation deserves its own pass. Adobe’s guide lists Arabic comma, semicolon, and question mark as well as Hebrew geresh, gershayim, and maqaf. A generic comma or question mark can look acceptable at a glance while failing the document’s intended orthography or bidi behavior. Check the actual character, not just the shape you see on the screen.

“For example, in Hebrew, the numbers look like 58:12 in Word come out as 21:85 when you paste them into InDesign.”
— Adobe Community user

The example points to an important QA rule: compare a string at the source, after paste, and in the exported document. A defect can occur during entry, conversion, or display. Testing only the final screenshot won’t tell you whether the stored character order changed or the renderer placed a run differently.

For larger mixed-language files, a PDF table and multi-column CAT-tool layout review can help identify additional layout risks when text moves between formats. Keep a record of any directional marks you add, including the exact run they isolate and the application in which you tested them. Invisible characters are hard for the next editor to spot.

When to change the layout, and when not to¶

Not every RTL problem needs a document-wide redesign. Choose the smallest correction that matches the visible issue; broad changes can damage parts of the file that were already correct.

Change the layout when the document’s structure is wrong¶

Set RTL paragraph direction when a paragraph reads or aligns as LTR despite containing RTL text. Adjust page binding when a publication’s opening edge or spine relationship is wrong. Use a suitable composer when the script doesn’t shape or compose as intended. Apply these settings at the level where the problem occurs.

A right-to-left publication conventionally binds on the right according to Adobe’s Middle Eastern scripting guide. That convention doesn’t mean every page element should move to the opposite side. A logo, chart, photograph, or diagram needs a design decision of its own. Mirroring an illustration can change its meaning, and flipping a logo can produce an incorrect brand mark.

Don’t reverse characters to repair visual order¶

Unicode’s logical-order model means the stored character sequence should remain in reading order. A bidirectional display engine handles the visual presentation. Reversing a Hebrew or Arabic string by hand can produce a line that looks right in one view while breaking selection, search, copying, editing, or display elsewhere.

Don’t replace proper paragraph direction with right alignment alone. Alignment positions text within its frame; it doesn’t necessarily establish the directional behavior needed for mixed content. Don’t change Office’s display language and assume that the keyboard or document editing direction has changed as well. Microsoft’s Office guidance treats those settings separately.

Use explicit controls selectively¶

Directional marks and isolates can resolve an ambiguous mixed-direction run, but they also add invisible control characters that can complicate later editing. Unicode explains that isolates protect text outside the isolated run from its directional effects and encourages their use over embeddings in new documents when target-platform support is known. For web content, use HTML and CSS direction mechanisms rather than inserting explicit bidi formatting characters into the page text.

If you inherit a file with unexpected controls, inspect a small affected passage before editing the whole document. Compare the rendered result with the logical text, and remove or replace controls only when you know what they do. A blanket find-and-replace can create a new direction problem.

When a different workflow makes more sense¶

A layout correction won’t solve every input problem. If the source text has already been manually reversed or contains untracked directional marks, ask for a clean logical-order copy where possible. If a file moves between applications, test that exact route with a representative passage before laying out the whole publication.

For a book or brochure, check binding, page sequence, and spreads. For a form or report, focus on paragraph direction, tables, fields, and mixed numbers. For an online page, use the web platform’s direction controls rather than relying on desktop-only formatting characters.

Hebrew publications can also involve requirements beyond page direction when the final file is intended for an official use. For document-specific preparation, see notarized translation to Hebrew: requirements for Ukrainians in Israel. The RTL layout still needs its own technical review, even when the text has been translated or certified.

A practical RTL QA pass before delivery¶

A short, repeatable review catches more than a last-minute visual glance. Test representative content at the paragraph, page, and exported-file levels, and keep notes on any controls or application-specific settings you changed.

Use this checklist before delivery:

• Paragraphs: Confirm that RTL paragraphs have explicit RTL direction where the layout requires it. Check headings, captions, footnotes, and table cells separately.
• Mixed runs: Test a passage containing RTL text alongside Latin text, digits, and punctuation. Include the types of names, references, or labels that actually appear in the file.
• Lists: Check the position and sequence of bullets and numbering, not only the direction of the list text.
• Script punctuation: Verify Arabic and Hebrew punctuation characters rather than assuming visually similar marks behave the same way.
• Shaping and composition: Confirm that the chosen composer supports the script and that the resulting line breaks and text frames look as intended.
• Binding: Check the publication’s binding separately from paragraph direction.
• Page sequence: Inspect the first spread, a middle spread, and the last page in the exported file.
• Copy and search: Select and copy a mixed-direction passage into a test area. Confirm that the logical character order remains usable.
• Export: Reopen the delivered file in the intended viewing environment and repeat the mixed-run checks there.
• Change notes: Record any inserted LRM, RLM, or isolate controls so another editor can identify them later.

A good test passage contains more than plain prose. Include a Hebrew or Arabic sentence with an English name, a number, and punctuation. Add a list item or table cell if the publication uses those elements. The test should represent the parts most likely to break, not just the simplest line in the document.

Don’t treat a screen capture as proof that the underlying text is sound. A screenshot records appearance, not logical character order. Selectable text, copy-and-paste behavior, and the exported document all matter when another person needs to edit or reuse the file.

The final review should answer three separate questions: Does the text read in the intended direction? Does the publication open and sequence pages as intended? Does the exported file preserve both behaviors? A “yes” to one doesn’t guarantee a “yes” to the others.

FAQ¶

Why do Hebrew or Arabic numbers and punctuation appear in the wrong order in InDesign?¶

Numbers have weak bidirectional types, while punctuation and spaces can be neutral. Their displayed positions depend on paragraph direction and surrounding strong characters, so check the paragraph and isolate mixed-direction runs rather than reversing the string.

How do I set right-to-left paragraph direction in Microsoft Word?¶

Enable the relevant RTL language, then choose the Right-to-left paragraph button in the Paragraph group on the Home tab. Microsoft says the button appears when an RTL language is enabled.

How should page binding and page order be set for a Hebrew or Arabic publication?¶

Set the document’s page binding to right-to-left for a conventional Hebrew or Arabic publication. Keep that setting separate from the paragraph direction used for text inside each frame.

Why do English text and numbers jump around inside Arabic or Hebrew paragraphs?¶

The Unicode Bidirectional Algorithm lays out strong, weak, and neutral characters according to their directional properties and context. Mark a mixed-direction run deliberately when context alone doesn’t produce the intended display.

Should I reverse Hebrew or Arabic text characters to fix an RTL layout?¶

No. Unicode text is stored in logical order, and bidirectional layout changes its visual presentation. Reversing characters generally damages the underlying sequence instead of fixing the layout.