A Hebrew reference that reads 58:12 in Word and appears as 21:85 after pasting into InDesign can look like a simple reversal, but the cause is often the interaction between paragraph direction, character direction, and punctuation. The fix usually isn’t to flip the entire line.
The same problem shows up in Arabic layouts: Latin product names, dates, phone numbers, URLs, and digits sit inside a paragraph that reads right to left. InDesign has to work out how those directional runs fit together. When one setting or imported style disagrees with the rest, the result can look scrambled even when the underlying text is intact.
What “backwards” means in an RTL paragraph¶
Arabic and Hebrew paragraphs normally read from right to left. Latin words and many numbers within those paragraphs generally read from left to right. A line containing both directions is bidirectional text, or bidi text: it isn’t a single string that should simply be reversed. Unicode’s Bidirectional Algorithm describes how text with mixed directional behavior gets displayed.
That distinction matters when diagnosing a problem. If the characters look wrong on the page, the text may still be stored in the order it was typed. Unicode uses logical order for the underlying text and applies its bidi algorithm to determine the displayed order. A screenshot alone can’t tell you whether the text was entered backward or whether the display rules resolved it unexpectedly.
A line can contain several directional runs¶
Take an Arabic sentence that includes an English product name and a date. The Arabic words set the paragraph’s overall reading direction. The English name forms a left-to-right run. The date contains digits and punctuation, each of which can interact with its neighbors. InDesign has to compose all those parts into a readable line.
Changing the direction of the whole paragraph doesn’t mean each character should now be read from right to left. Forcing a Latin word into RTL direction can reverse its visible order. The paragraph’s direction and the direction of a specific character run are related settings, but they’re not the same setting.
Unicode explains the basic mix this way:
“Whenever right-to-left scripts, for example, use digits that are written from left to right, the text is actually bidirectional: a mixture of right-to-left and left-to-right text, even in the same script.”
That description is useful because it replaces the idea of a globally “backward” line with a more precise question: which run has the wrong direction or context?
Numbers and punctuation don’t behave identically¶
Most numbers have weak bidi types, and many punctuation marks and symbols are neutral. “Weak” and “neutral” are terms for how the bidi algorithm classifies characters when deciding how to display a line. A colon, slash, percent sign, parenthesis, or dash may be placed according to nearby text rather than following a fixed direction on its own. Unicode’s bidi FAQ explains why punctuation can appear unexpected even when the digits themselves are intact.
For example, a date such as 12/05/2025 combines digits with slashes. A time such as 09:30 combines digits with a colon. A reference like 58:12 may have an intended reading order that is clear to its author, while the punctuation makes the rendered result ambiguous in an RTL context.
Arabic and Hebrew agree that the most significant digit in a simple number is on the left. But presentation of a whole number in context, including separators and punctuation, can vary by script and, for Arabic, by numeral set. The Unicode FAQ discusses that distinction; don’t assume every date, decimal, or reference will be resolved the same way in every surrounding phrase.
“Reversed” can describe different faults¶
Before changing anything, identify what looks wrong:
- The Latin word reads backward. The English or other Latin run may have inherited RTL character direction.
- The digits appear in reverse order. The number run, paragraph context, or pasted formatting may be affecting how the digits display.
- The digits are correct, but punctuation moved. A slash or colon can resolve differently because punctuation is context-dependent.
- The line starts from the wrong side. Paragraph direction or alignment may be wrong even if the characters themselves are fine.
- The whole paragraph changes after a composer switch. The composition engine is affecting more than the troublesome run.
Those symptoms point to different settings. Treating all of them as “Arabic text is reversed” encourages broad changes that can damage correct Arabic or Hebrew text while leaving the actual problem untouched.
How InDesign handles direction and composition¶
InDesign has several controls that affect RTL text, and each one solves a different part of the problem. Paragraph direction sets the direction of a paragraph. Story direction is a separate setting for a text story. Character direction affects a selected run. The composer determines how text is composed into lines. Adobe’s Middle Eastern Scripting Guide documents separate story and paragraph direction settings, as well as a dedicated World-Ready composer.
Paragraph direction isn’t character direction¶
Adobe’s scripting guide says a newly created InDesign paragraph has left-to-right direction by default. The guide also describes changing a paragraph’s direction to right to left. That means an RTL document can contain a paragraph that still has an LTR direction unless the paragraph setting or its style has been changed.
Paragraph direction tells InDesign how to handle the paragraph as a whole. Character direction applies to the selected characters. A right-aligned paragraph isn’t necessarily an RTL paragraph: alignment controls where lines sit in the frame, while direction affects how text runs and punctuation are interpreted. Moving text to the right edge alone doesn’t make it behave like Arabic or Hebrew text.
Story direction is separate again. Adobe’s scripting guide exposes left-to-right and right-to-left options for existing stories. A story may contain multiple paragraphs, so check whether the issue belongs to one paragraph or to the whole story before changing a story-wide property.
The composer determines line composition¶
A composer is the component that lays out text into lines. Adobe documents an Adobe World-Ready Composer for RTL scripts and a method that changes a standard Paragraph Composer to Adobe World-Ready Paragraph Composer. The same method maps Single-line Composer to World-Ready Single-line Composer. See Adobe’s documentation for those composer options.
The World-Ready composer is a sensible setting to check when a paragraph mixes Arabic or Hebrew with Latin text. It doesn’t replace paragraph direction, and it can’t make every pasted run correct by itself. If one number has a character-level override, switching the composer may not address that override.
A standard composer can make an example appear better by changing how a line is composed, but the result may come at a cost elsewhere. In a 2025 Adobe Community report, a user said a Hebrew reference changed from 58:12 in Word to 21:85 after pasting into InDesign despite using World-Ready Paragraph Composer. Switching to the standard composer changed the Hebrew paragraph too. The example shows why a paragraph-wide composer change isn’t a safe first move: it can change the text around the number as well.
Fonts and glyphs are a different question¶
A direction problem changes how characters are ordered on screen. A font problem changes which glyphs are available or how they look. If a word appears as boxes, missing characters, or visibly different letter shapes, check font support and character coverage rather than treating the problem as bidi order.
If letters and digits are present but appear in an unexpected sequence, focus first on direction and composition. Unicode’s algorithm determines displayed ordering based on characters’ bidirectional classes; a font doesn’t decide whether a Latin run should read left to right inside an RTL paragraph. The Unicode bidi FAQ describes the directional behavior of Latin letters, Arabic and Hebrew letters, and neutral punctuation.
A targeted workflow for fixing reversed words or numbers¶
Start with the smallest affected text range. A number-only problem doesn’t justify changing every paragraph in a document, and a paragraph-wide fix shouldn’t be your first response to one misplaced colon.
1. Check the actual text before editing direction¶
Select the affected text and inspect what characters are present. If the number is meant to be 58:12, check whether the content itself is in that logical order rather than relying only on its rendered appearance. Copying the text into a plain-text environment can help you distinguish the stored sequence from InDesign’s display, though the display in another application can also depend on its own bidi handling.
Unicode says directional formatting affects rendered order rather than changing the underlying logical sequence. A reversed-looking display therefore doesn’t prove someone typed the characters backward. Read the text as data before rearranging it.
2. Verify paragraph direction and composer¶
Check the paragraph that contains the problem. Confirm that its direction matches the language and layout, then inspect the composer in the Paragraph panel. For RTL content, check whether Adobe World-Ready Paragraph Composer is in use.
Adobe’s community advice for flipped Arabic numbers after placing a Word document was to check both right-to-left text direction and Adobe World-Ready Paragraph Composer. The reply was posted on June 18, 2025. Treat that as a useful troubleshooting recommendation, not a universal guarantee: a local character override or different import behavior may still be involved.
3. Inspect only the affected character run¶
If Arabic or Hebrew text reads correctly and only one number or Latin word is wrong, select that run rather than the whole paragraph. Check Character Direction in the Character panel and compare the setting with the intended reading direction of that run.
A user working with Farsi numerals in an Arabic InDesign file reported that the numbers flowed in the wrong direction. The solution excerpt in the Adobe Community thread, dated August 20, 2020, recommends selecting the affected number and setting Character Direction through the Character panel. The narrow scope is the useful part: a number-run adjustment can avoid changing the Arabic paragraph around it.
Don’t set every digit to Right to Left just because the paragraph is RTL. Digits in a mixed-direction line have their own bidi behavior. The right setting depends on what the run is meant to display and how the surrounding text is resolved.
4. Compare Place with paste¶
A Word file can behave differently when you place it in InDesign versus when you copy and paste its text. Adobe Community users have reported that a placed Word file may preserve paragraph direction, while pasted text may retain only raw text or inconsistent clipboard formatting. The discussion about Arabic digit order, posted on November 12, 2023, highlights the importance of checking import method and overrides.
For a repeatable test, use the same short sample in both workflows and compare paragraph style, direction, composer, and character-level settings. If the placed version works and the pasted version doesn’t, focus on what was lost or changed during paste rather than rebuilding the entire paragraph by hand.
5. Check styles and overrides¶
A paragraph style can set direction and composer-related attributes. Character styles or local overrides can affect a selected run. When the same text behaves differently in different parts of the document, compare those attributes before rewriting the copy.
A direct formatting change may fix the visible problem while leaving the paragraph style incorrect. The next paragraph based on that style can then reproduce the fault. If you correct a style, test it on other RTL paragraphs that use it, especially where Arabic or Hebrew shares a line with Latin text or digits.
6. Retest a complete line, not just a selected number¶
After a change, read the entire line in context. Check the adjacent Arabic or Hebrew, the Latin word, digits, punctuation, and the order of nearby phrases. A local adjustment can make one number look right while moving a slash, colon, parenthesis, or neighboring word into an unexpected place.
Unicode defines directional formatting controls for special ambiguous cases, but the bidi algorithm handles ordinary mixed-direction text implicitly. Treat directional controls as a targeted remedy, not a routine fix for every paragraph. UAX #9 also distinguishes isolates from embeddings: text inside an isolate doesn’t affect the ordering of text outside it, unlike text inside an embedding. Unicode 6.3 introduced isolates, and the standard encourages their use in new text when the target platform supports them. InDesign workflows should use such controls only when the specific case calls for them and the receiving environment handles them correctly.
Common traps, and when a direction fix isn’t needed¶
The most damaging fixes tend to be the broadest ones: reversing the entire string, changing the composer for a whole document, or applying RTL character direction indiscriminately. A careful check of the scope of the fault usually prevents collateral changes.
Reversing characters by hand¶
If InDesign displays a number incorrectly, manually retyping it in reverse order can make the stored text wrong. The display may change again when the number moves to a different sentence, is exported, or is opened in another application. Unicode’s logical-order model means the display order and the stored character sequence aren’t interchangeable.
Use a manual reorder only when the underlying characters really are in the wrong sequence. Confirm that from the text itself, not from a single screenshot.
Changing the whole paragraph to solve one number¶
A paragraph-wide composer change can affect every word and line in the paragraph. The 2025 Hebrew example shows a number changing while the Hebrew paragraph also changed. That doesn’t mean the standard composer is never appropriate; it means the change should be tested against the whole paragraph.
Keep a copy of the original settings or test on a duplicate paragraph before applying broad changes. Compare the full line and surrounding text, not just the digits that triggered the investigation.
Treating punctuation as part of the number¶
A colon or slash can move even when the digits remain in the intended sequence. Unicode classifies many punctuation marks as neutral and most numbers as weak, so surrounding directional characters can influence the final display. The Unicode FAQ explains why separators and punctuation in whole numbers can look different by script and numeral set.
For a date or reference, check the complete expression with its punctuation. If the digits are correct but a separator is out of place, changing the direction of every digit may make the result worse.
Assuming a pasted Word string should match exactly¶
A paste operation may not preserve the same formatting and direction information as placing a Word file. When the same content behaves differently across those methods, compare imported styles and local direction overrides before changing the text. The Adobe Community discussion from November 12, 2023 describes source and import method as relevant troubleshooting details.
A Word-to-InDesign mismatch isn’t proof that Word has the correct underlying order or that InDesign has corrupted it. Check the character sequence, then compare how each application resolves the mixed-direction line.
Confusing page binding with text direction¶
Arabic and Hebrew publications conventionally bind on the right, while Roman publications bind on the left, according to Adobe’s Middle Eastern Scripting Guide. Page binding affects the publication’s layout as a whole. It doesn’t determine whether a Latin product name or a number reads correctly inside a line.
If the page sequence or page layout is mirrored, see how to fix mirrored RTL layouts. If the issue is specifically mixed Arabic and English text, this guide to bidirectional text focuses on how those runs interact.
When no direction adjustment is needed¶
A Latin word that reads normally from left to right inside an RTL paragraph is behaving as expected. Digits that remain in their intended order while punctuation sits unexpectedly may need a context-specific solution rather than a general reversal. A right-aligned line isn’t automatically wrong simply because its text begins on the right.
Stop changing direction settings once the text sequence, paragraph flow, and punctuation match the intended reading. Extra overrides can make the file harder to edit and create new problems when content changes.
For a broader Arabic layout problem, including paragraph flow and alignment, see Arabic RTL layout troubleshooting. If the source is an IDML translation workflow, the IDML round-trip guide covers a different set of file-handling concerns.
FAQ¶
Why are numbers reversed in an Arabic InDesign document?¶
Arabic paragraphs read right to left, but most digits have weak bidi types and commonly display left to right. A number can look reversed because of paragraph context, a character-direction setting, or punctuation placement. Check the composer and direction settings before retyping the digits.
How do I keep English words left to right in an Arabic InDesign paragraph?¶
Set the paragraph direction to right to left and check Adobe World-Ready Paragraph Composer. Keep the English word as a left-to-right run, and inspect Character Direction if only that word is wrong. Don’t apply RTL direction to every character in the line.
Which InDesign composer should I use for mixed Hebrew and Latin text?¶
Check Adobe World-Ready Paragraph Composer for mixed RTL and LTR text. Adobe documents it as a dedicated World-Ready composer, but it doesn’t automatically remove character-level overrides or fix every imported text issue. Verify the paragraph and run settings too.
Why does a date look reversed after pasting from Word into InDesign?¶
Pasted text may not retain the same direction and formatting information as a placed Word file. Compare both import methods, then inspect paragraph direction, composer, character direction, and punctuation. Unicode’s bidi rules can place separators differently depending on surrounding text.
Should character direction be Default or Right to Left for Arabic numerals in InDesign?¶
Don’t apply Right to Left to every number just because the paragraph is Arabic. Select the affected number run and check its behavior in context; a targeted setting may solve the problem without changing the paragraph. The intended reading order matters more than a blanket rule.
Can a reversed-looking number mean that the text was typed backward?¶
Yes, but appearance alone doesn’t establish that. Unicode stores text in logical order and applies bidi rules to its displayed ordering. Check the underlying character sequence before editing or retyping a number.
Do I need to use directional control characters for every Arabic-English line?¶
No. Unicode’s bidirectional algorithm handles ordinary mixed-direction text implicitly. Directional controls are for specific ambiguous cases, and they should be used only after checking the paragraph and character settings and confirming support in the target workflow.
Why does changing the composer fix the number but alter my Hebrew paragraph?¶
A composer change affects paragraph composition, not just the number that caught your attention. A user reported this behavior in a March 3, 2025 Adobe Community discussion. Check the affected run and its direction before changing the composition engine for the whole paragraph.