A Hindi paragraph can contain all the right Unicode characters and still look wrong in an InDesign frame: a vowel mark may sit in the wrong place, a consonant sequence may fail to form a conjunct, or the lines may break in an awkward spot. The paragraph composer is one setting worth checking, but it isn’t the only part of the chain.
Adobe World-Ready Paragraph Composer helps InDesign arrange text that needs more than straightforward left-to-right placement of separate Latin letters. For Hindi, Tamil and Bengali, a reliable result also depends on the script, the font, the underlying text and the exported PDF. A good workflow checks each of those layers instead of treating a composer change as a universal repair.
What World-Ready Composer does¶
A paragraph composer decides how InDesign lays out text across a paragraph. It considers such details as line breaks and spacing, and a composer designed for world-ready text can handle the shaping needs of complex writing systems more appropriately than a composer intended for simpler text.
The word shaping describes how a sequence of encoded characters becomes the visible text a reader sees. A script may need characters to combine, change shape or appear in an order that doesn’t match the order in which a person types or reads the code points. A font supplies the glyph designs; the shaping and composition process works out how those glyphs appear together in context.
That distinction matters when troubleshooting. The composer doesn’t create missing font characters, repair damaged source text or guarantee that an exported PDF will expose text correctly to assistive technology. Each part of the production chain has a different job.
Unicode describes South Asian scripts as generally written from left to right and as abugidas. In an abugida, a consonant commonly carries an inherent vowel, and additional signs can change that reading. Unicode also explains that a virama is a combining character that nominally suppresses the inherent vowel of the consonant to which it applies. The visible form of the sign varies by script (Unicode Standard 17.0.0, Chapter 12).
In practical terms, a string of text isn’t necessarily a row of independent character pictures. The same underlying sequence can need contextual rendering to show a reader the intended combination. That’s why checking only whether the characters are present in the story isn’t enough.
Hindi uses Devanagari. Bengali uses the Bangla script, and Tamil uses the Tamil script. Unicode includes these as distinct scripts in its Indic encoding discussion, and it cautions that similar encoding structures don’t mean that South Indian scripts render like Devanagari (Unicode Standard 17.0.0, Chapter 12). A successful Hindi test therefore doesn’t prove that a Tamil or Bengali paragraph will look right.
Adobe’s documentation describes World-Ready Composer as a composition option for world-ready text and provides guidance on its use (Adobe World-Ready Composer overview). Treat the feature as one part of a typesetting workflow, not as a switch that makes every font, language and PDF behave identically.
Composer versus font versus text¶
These three pieces are easy to confuse:
| Piece | What it does | What to inspect |
|---|---|---|
| Composer | Lays out the paragraph and handles composition decisions | Whether the paragraph uses a composer suitable for the script |
| Font | Provides the glyph designs used to display characters | Whether the chosen font supports the characters and combinations in the text |
| Source text | Supplies the encoded characters | Whether characters are present, in the intended sequence, and from the expected script |
A wrong-looking mark can come from more than one layer. If changing the composer doesn’t help, don’t keep toggling composers and assume InDesign is at fault. Inspect the font and the source text next.
An Adobe Community Expert recommended selecting the Hindi text and changing its composer from the Paragraph panel flyout:
“Try changing the paragraph composer of hindi text to Adobe Word Ready Composer. Select the text and then use the flyout menu of paragraph panel to change the composer.”
That advice comes from a Hindi troubleshooting thread, not from a guarantee that the same change will fix every font or document (Adobe Community thread, discussion dated 2019-11-30). The useful takeaway is a focused test: change the paragraph’s composer, then inspect the result. If the glyphs remain absent or wrong, test the other layers.
How to set it for a paragraph or a style¶
A one-paragraph test is a good way to see whether the composer changes the problem before you edit a whole document. Work on a copy or a test frame, especially when an existing layout has many styles and overrides.
- Choose a representative paragraph. Use text that contains the feature you’re trying to check, such as a vowel mark, a consonant combination or a line break that currently looks wrong. A paragraph made only of isolated basic characters won’t test much.
- Select the paragraph or place the text cursor in it. The setting belongs to paragraph composition. Selecting the paragraph makes the target clear; placing the cursor in it lets InDesign apply the paragraph setting without selecting every character.
- Open the Paragraph panel. Use its flyout menu to locate the paragraph-composer options.
- Choose Adobe World-Ready Paragraph Composer. The exact wording can vary slightly across interfaces and versions. Adobe Community advice for Hindi specifically points to changing the composer through the Paragraph panel flyout (Adobe Community thread, discussion dated 2019-11-30).
- Inspect the paragraph in context. Check the marks and combinations, the line endings, spacing, and any interaction with adjacent Latin text or punctuation. Don’t judge the change from a single enlarged glyph alone.
- Check the font if the problem persists. A composer change can’t supply a glyph that the font doesn’t include. Unicode identifies Devanagari as the script used for Hindi, so check Devanagari coverage rather than choosing an unrelated font simply because its description says it supports Indian languages (Unicode Standard 17.0.0, Chapter 12).
When a document has many paragraphs that should share the same setting, a paragraph style is usually a more consistent place to manage it than making local changes one paragraph at a time. Edit the relevant style, locate the composer setting in the style’s paragraph-related options, select the World-Ready composer and apply the style to the intended text.
An InDesign user’s Hindi troubleshooting thread includes follow-up advice about changing the composer in paragraph styles when many paragraphs need the same setting. That’s practical forum guidance rather than a product guarantee (Adobe Community thread, discussion dated 2019-11-30). After updating a style, check for local overrides: an individual paragraph can differ from the style if a local setting has been applied.
A simple test document helps isolate the cause. Put the same text in separate frames, apply the same font and paragraph style, and change only the composer between the frames. Compare like with like. If the result changes, the composer is part of the issue. If the same glyph remains missing in both frames, check the font and source text before adjusting the layout further.
What to check after changing the style¶
Look at the actual text, not just the style controls. Check whether marks sit where they belong, whether combinations form as expected, and whether line breaks make sense. Include a heading, body paragraph and any short label that uses the script if those text types use different paragraph styles in production.
A style can standardize a setting, but it can’t make two different fonts behave alike. If the heading uses one family and the body uses another, test both. The same applies when text is pasted from another application: the paragraph can carry formatting or characters that differ from the rest of the document.
For a broader production decision, InDesign vs Word for multilingual layout explains how to think about the layout tool itself. If a translation workflow involves an InDesign source file, a safe IDML round-trip workflow can help frame the file-handling questions separately from script rendering.
Test Hindi, Tamil and Bengali independently¶
Indic scripts share some structural features, but a shared label doesn’t make them interchangeable in a typesetting test. Hindi uses Devanagari; Bengali uses Bangla; Tamil uses Tamil script. Unicode’s chapter groups these scripts within its South Asian encoding discussion while explicitly warning against assuming that one script’s rendering model applies to another (Unicode Standard 17.0.0, Chapter 12).
That difference affects what a useful test looks like. A Hindi sample should contain Devanagari text representative of the actual document. A Bengali sample should use Bangla text and the intended Bengali font. A Tamil sample should use Tamil text and be checked on its own merits. Passing one script’s test doesn’t establish that another script’s font coverage or composition is correct.
Unicode also shows why a single Hindi-centred explanation can lead you astray. Hindi uses the term halant for the consonant whose inherent vowel is suppressed; Tamil uses puḷḷi for the relevant sign. The marks and terminology vary by script, even where the underlying encoding concepts have similarities (Unicode Standard 17.0.0, Chapter 12).
A practical language-by-language test can use the same checklist:
- Confirm that the text is in the expected script, not a visually similar or incorrectly encoded substitute.
- Confirm that the font is intended for that script and supports the text being used.
- Apply the World-Ready composer and inspect the output in a representative paragraph.
- Check the text in the context of the real layout, including mixed-script passages if the document contains them.
- Export a PDF and check its visible appearance separately from its selectable text and accessibility behaviour.
The checklist doesn’t require a large specimen sheet. It requires a sample that reflects the document’s actual challenges. A short heading may not reveal a line-break issue. A paragraph containing no combining marks may not reveal a mark-placement problem. Use a representative passage from the material being typeset, and get a language-aware reviewer to confirm that the visible result reads correctly.
Why Hindi, Bengali and Tamil need distinct checks¶
Hindi is written in Devanagari, so a font’s Devanagari support is the relevant coverage question. A font marketed broadly for Indian languages may not support every Indic script, or may support one script better than another. Unicode’s description of Devanagari’s use for Hindi gives a precise basis for that check (Unicode Standard 17.0.0, Chapter 12).
Bengali and Bangla refer to the same script in this context. A Bengali font test should use the font intended for Bangla text, and the final PDF needs its own review. A layout that looks right in InDesign can still have a separate text-encoding or accessibility issue after export.
Tamil also needs its own test rather than being treated as Devanagari with different-looking glyphs. Unicode specifically cautions that similar encoding plans don’t mean South Indian scripts render like Devanagari (Unicode Standard 17.0.0, Chapter 12). The safe production choice is to verify the actual Tamil text and font in the actual file.
When World-Ready Composer helps, and when it doesn’t¶
World-Ready Composer is worth testing when a paragraph’s Indic text looks incorrectly composed in InDesign. A Hindi user asked about rendering problems, and an Adobe Community Expert suggested switching the selected Hindi paragraph to Adobe World-Ready Paragraph Composer. The recommendation is a troubleshooting path, not proof that the composer alone solves every case (Adobe Community thread, discussion dated 2019-11-30).
A Bengali user described a separate case in which the standard composer corrupted the visual formatting and the World-Ready composer corrected the formatting in InDesign. That report is one user’s experience, not a universal statement about all Bengali documents (Adobe Community report, dated 2025-04-30).
“using the standard composer it corruupts the formatting of the letters (in in design) however it passes accessibility in the PDF.”
The poster is describing a difference between visible composition in InDesign and the PDF accessibility workflow. The forum post doesn’t establish a general rule that the standard composer will damage Bengali text or that its PDF output will always pass accessibility checks. It does show why testing only one outcome can hide a problem in another.
A composer change isn’t the right fix when the problem is missing glyphs. In a separate Hindi support discussion, an Adobe Community Expert said missing glyphs were likely a font problem and suggested trying other fonts. Because the available information is a search-result lead rather than a fetched and verified page, treat it as a prompt to inspect font coverage, not as a definitive diagnosis (Hindi Characters Missing / World-Ready Para not solving issue).
The same restraint applies to source text. If the text contains the wrong characters, a font or composer setting can’t silently turn the source into the intended language. Check the text itself with someone who can read the script. Don’t decide that a paragraph is correct just because its characters render as ink on a page.
A composer change can also alter line composition, so the paragraph may reflow even when individual glyphs look better. Review the full frame after changing it. Watch for overset text, changed line endings, unexpected spacing and effects on adjacent Latin text. The goal is correct, readable typesetting, not simply a different arrangement.
The case for changing composers is therefore specific: use it as a controlled test when complex-script text appears wrongly composed. The case against treating it as a universal repair is just as important: missing glyphs, wrong source characters and PDF text extraction are separate problems.
Troubleshooting and PDF quality checks¶
A useful troubleshooting pass follows the problem from source text to final output. Changing several settings at once makes it harder to know what fixed the issue, so isolate the likely cause and recheck the same sample after each adjustment.
Start with the visible symptom. Identify whether the problem is a missing character, a misplaced mark, a combination that fails to form, awkward line breaks or a PDF issue. These symptoms point toward different parts of the workflow.
Check the source text. Confirm that the paragraph contains the intended script and characters. Unicode describes Indic writing systems as abugidas, with consonants that can carry an inherent vowel and signs that can modify how they are read (Unicode Standard 17.0.0, Chapter 12). A language-aware reviewer can help distinguish a typesetting fault from incorrect source text.
Check the font. Verify that the chosen font supports the script and the characters in the sample. For Hindi, the relevant script check is Devanagari, not a general claim that a font handles Indian languages. A composer switch won’t supply missing glyphs.
Test the composer on a controlled paragraph. Apply World-Ready Paragraph Composer to the test paragraph or its style. Keep the font and text constant so the comparison tells you what the composer changed.
Review the whole layout. Check the paragraph in its frame and in surrounding text. A glyph can look correct at close range while the paragraph still has a bad line break, spacing issue or overflow problem.
Export and inspect the PDF as a separate deliverable. Check visible appearance and, where relevant, confirm that text can be selected, searched or handled by the accessibility workflow. Don’t infer PDF behaviour from the InDesign canvas.
The Bengali forum report makes the final distinction concrete. The user said World-Ready Composer corrected the visual formatting in InDesign but the exported PDF still had a character-encoding problem in the accessibility workflow. The user also reported testing Noto Sans Bengali, Adobe Bengali, Myriad Bengali and Tiro Bangla in that document and workflow (Adobe Community report, dated 2025-04-30).
“When i use the Adobe world ready composer it corrects the formatting issue in indesign but when it fails character encoding in the PDF”
The forum post doesn’t prove that those fonts or World-Ready Composer cause PDF encoding failures generally. The lesson is narrower and more useful: a correct-looking InDesign layout doesn’t by itself confirm that PDF text encoding or accessibility works. Test the exported file, and investigate the PDF workflow separately if text selection or assistive use fails.
Version differences deserve the same care. An InDesign team reported that Indian-language text displayed differently between versions 19/20 and version 18 despite stating that the settings and fonts were the same. The report was posted on 2025-03-22 and doesn’t establish a general version defect (Adobe Community thread, dated 2025-03-22). The original poster later said enabling legacy support worked on that computer. Treat that as a reported workaround for that case, not as a universal fix.
For a production file, record the InDesign version, operating environment, font and composer used for the test. If a document behaves differently on another workstation, those details make it easier to reproduce the issue. Before changing a shaping-engine preference, check Adobe’s current guidance for changing the World-Ready Composer shaping engine (Adobe instructions for changing the shaping engine).
Avoid making a preference change on a live production file just because a forum user reported success. Test on a copy, check the result with the relevant script, and compare the exported PDF too. A workaround that changes one workstation’s rendering may not solve a font or encoding problem in a different file.
If the layout looks wrong after translation, the source file and output format can affect the next steps. Rebuilding a PDF layout or converting the PDF to InDesign covers that separate production decision. For documents where the InDesign source file isn’t available, translating a PDF without its InDesign source is another related workflow.
FAQ¶
How do I enable World-Ready Composer for Hindi in InDesign?¶
Select the Hindi paragraph, open the Paragraph panel flyout menu and choose Adobe World-Ready Paragraph Composer. An Adobe Community Expert gave this as a Hindi rendering troubleshooting step in a thread dated 2019-11-30, but the change isn’t a guarantee for every font or file (Adobe Community thread).
How do I apply World-Ready Paragraph Composer to an InDesign paragraph style?¶
Edit the paragraph style used by the relevant text and choose the World-Ready composer in its paragraph-composition settings. A Hindi troubleshooting thread also discusses using paragraph styles when many paragraphs need the setting; check the resulting text for local overrides after applying the style (Adobe Community thread, discussion dated 2019-11-30).
Why do Hindi matras and conjuncts look wrong in InDesign?¶
A composer that doesn’t handle the paragraph as intended can affect shaping, but a font without the required glyphs or incorrect source text can cause a similar symptom. Test the composer, font and text separately; Unicode identifies Devanagari as the script used for Hindi (Unicode Standard 17.0.0, Chapter 12).
Does InDesign World-Ready Composer support Tamil and Bengali?¶
World-Ready composition is relevant to complex-script text, but test Bengali and Tamil with their own text samples and fonts. Unicode says that similar encoding structure doesn’t mean South Indian scripts render like Devanagari, so a successful Hindi test isn’t enough (Unicode Standard 17.0.0, Chapter 12).
Why can Bengali look correct in InDesign but have PDF accessibility or encoding problems?¶
InDesign’s visible composition and a PDF’s text encoding or accessibility are separate checks. A Bengali user reported that World-Ready Composer corrected the visual layout but an encoding problem remained in that document’s exported PDF accessibility workflow (Adobe Community report, dated 2025-04-30).
Does changing the composer fix missing Hindi glyphs?¶
No. A composer controls composition; it doesn’t add glyphs to a font. Check whether the font supports the Devanagari characters in the text, and verify the source text with a Hindi reader if the characters themselves may be wrong.