Multilingual Desktop Publishing (DTP) Services

Most DTP work is everyday material that has to look as good in every language as it does in English: brochures, leaflets and posters, annual and impact reports, guides and manuals, catalogues, packaging and labels, presentations, forms and e-learning screens. We set the translation into your design, handle text expansion and line breaks, and return files your printer or web team can use straight away.

• Design files: Adobe InDesign (INDD and IDML), Illustrator (AI) and Photoshop (PSD).
• Office files: Word, PowerPoint and Excel.
• PDF only: when there is no source file, we rebuild the layout from the PDF.
• What you get back: a print-ready PDF with fonts embedded, plus the edited source files.

Right-to-left scripts such as Arabic, Farsi, Urdu and Pashto are mirrored correctly, and Chinese, Japanese, Korean and Indic scripts are set with the right fonts and line-break rules.

DTP is priced per page, so you know the cost before we start. Translation is priced separately, per word.

• Simple layouts (mostly text): £8 a page.
• Complex layouts (images, tables, charts or several columns): £15 a page.
• Hourly rate, where per-page pricing does not fit: £55 an hour.
• Right-to-left scripts (Arabic, Persian and Urdu): add 50%.
• Chinese, Japanese and Korean: add 25%.
• PDF only, no source file: add 50%, because the layout has to be rebuilt.

Prices exclude VAT. We confirm a fixed price for your files before any work starts.

In July 2026 we delivered a Welsh Government public information document in 17 languages from one 850-word English source. Our desktop publishing team set every language in the original layout, including right-to-left Arabic, Dari, Farsi, Pashto and Urdu and the Indic scripts for Bengali, Gujarati and Nepali, and the files went back print-ready. Read the Welsh Government case study.

Send your files through our contact form with the languages you need and your deadline. A PDF of the design is enough for us to price the job. If you have InDesign or Illustrator files, say so in your message and we will arrange how to receive the packaged files with their fonts and links.

We reply with a fixed price, and nothing starts until you approve it. Prefer to talk it through? Call us free on 0800 193 8888.

The hardest DTP job is the one where there is no source file. A French tax return, a German CE safety leaflet, a clinical patient information leaflet (PIL), a patent filing - all of these are PDFs the client received from a regulator or an agency, with no editable InDesign or Word original behind them. Most translation agencies handle this by extracting the text into a Word document, translating, and sending the translation back as a fresh document that does not match the regulator's template. This is unacceptable for filings - the regulator expects the original form back, in the target language, looking exactly like the original.

The technical problem

PDFs do not store text as text. They store text as a sequence of glyph operations: "draw character 67 from font Helvetica at coordinate (123, 456)". Most agencies use a PDF-to-Word converter that loses the coordinate information and the font references; the result is editable but visually unrelated to the source. The next level of agency uses Adobe Acrobat's "Export to InDesign" - this preserves more layout but breaks on three categories of content:

• Outlined glyphs. Many regulatory forms (impots.gouv.fr, German Steuererklärung, AEMPS) outline their text labels to a vector path at publication. Acrobat's extractor reads outlined text as a graphic, not a string. The translator never sees the field label and the regulator never sees its template back.
• Form fields. AcroForm and XFA fields have their own text and font references. Extracting the surrounding text but not the field labels produces a half-translated document.
• Scanned hybrids. A PDF that is part vector, part raster (typical for regulator-supplied documents with a scanned signature block) needs OCR on the raster portion and coordinate-preserved extraction on the vector portion. A single tool cannot handle both.

Our engine

We built our PDF engine specifically for this category. It enumerates every text-drawing operation in the PDF, including outlined glyphs (by detecting common label fonts and reverse-mapping the path back to characters), reads form field labels and tooltips, runs OCR over raster regions, and produces a per-span translation manifest. The translator works in the manifest; the engine writes the translation back at the source coordinates. Form fields are preserved; the regulator sees the same form, in their target language, with the right field labels.

What this delivers

A French tax return that looks like a French tax return. A German CE leaflet that matches the German regulator's template. A patient information leaflet that the EMA accepts on first review. We were built for this; most agencies were not.

RTL typesetting is the single biggest skill gap in UK DTP. Most agencies own InDesign but do not have the Middle East and North Africa Composer enabled, do not have an Arabic typesetter on staff, and outsource the work to a Cairo or Beirut studio. The round-trip introduces latency, version drift, and a translator-typesetter handoff that frequently breaks. We do this work in-house, in Cardiff, with native Arabic typesetters who have shipped this work for over a decade.

The Adobe World-Ready Composer

InDesign ships a default paragraph composer that cannot handle Arabic correctly - it breaks ligatures, gets the line-break logic wrong, and fails to apply contextual forms. The fix is to enable Adobe World-Ready Paragraph Composer (Type → Paragraph → World-Ready Paragraph Composer in the InDesign ME edition, or via a script in the standard edition). Most agencies running standard InDesign do not enable it and ship visually broken Arabic that a native reader will reject on sight.

Ligatures and contextual forms

Arabic glyphs change shape depending on whether they are isolated, initial, medial, or final in a word. A correctly typeset Arabic paragraph applies the correct form automatically through the OpenType init, medi, fina, and isol features. Fonts vary in how well they implement these features - Cairo, Noto Sans Arabic and Adobe Arabic are reliable. Many "Arabic" fonts on free repositories are not, and produce text that a native reader recognises as foreign-made on first glance.

Bidirectional flow in mixed content

An Arabic paragraph that contains an English brand name or a number flows in both directions. The Unicode Bidirectional Algorithm handles most cases, but punctuation at the boundary (a full stop after an English brand inside an Arabic sentence) is often placed on the wrong side of the brand. We use Unicode directional formatting marks (RLM, LRM) to anchor punctuation correctly, and we proof on the final layout - not in the InDesign editor, where the algorithm's behaviour differs from the exported PDF.

Numerals: Arabic-Indic vs Western

Arabic content can use Arabic-Indic numerals (٠١٢٣٤٥٦٧٨٩) or Western numerals (0123456789); the choice depends on regional convention and client house style. We confirm before commencing and configure the InDesign character style to enforce consistency throughout the document. A document that mixes both is a regional bug.

Persian and Urdu

Persian and Urdu share the Arabic script but have different glyph shapes, additional characters (Persian's پ, Urdu's ٹ), and different typographic conventions. Nastaliq is the dominant Urdu typeface; Naskh is dominant for Persian. Treating all three as "Arabic" is the most common error; we staff per-language typesetters.

Asian scripts each have a separate set of typographic requirements that Latin-trained typesetters routinely miss. We handle each in-house with operators trained on the script.

Chinese (Simplified and Traditional)

Chinese has no word spaces; line breaks can happen at any character boundary. InDesign's CJK composer handles this correctly when enabled. Punctuation kinsoku rules - Chinese full-width punctuation cannot appear at the start of a line - need explicit configuration. Vertical typesetting (for traditional contexts, books, and some marketing layouts) requires a separate composer and frame setup. Simplified Chinese uses one set of punctuation conventions and PRC orthography; Traditional Chinese uses another and we proof against Taiwan or Hong Kong house style depending on target.

Japanese

Japanese mixes three scripts (kanji, hiragana, katakana) with Latin characters and numbers. Ruby text (furigana - small phonetic readings above kanji) is required for some content categories (school materials, accessibility). Vertical typesetting is common in traditional contexts. Line-break rules are more permissive than Chinese but still have kinsoku constraints.

Korean

Korean Hangul uses word spaces (unlike Chinese and Japanese). Justification and tracking behave differently from Latin scripts; Korean readers expect tighter line spacing than the Latin default. Hanja (Chinese characters in Korean contexts) appear in academic and legal documents and require font fallback handling.

Thai

Thai is the script that breaks naive typesetters most often. There are no word spaces - line breaks must be inferred from a dictionary. InDesign's Thai composer uses a built-in dictionary; for technical terms not in the dictionary, manual zero-width-space insertion is required. Tone marks stack above consonants and cannot wrap to the next line. Most UK typesetters do not have a Thai operator on staff; we do.

Indic scripts: Devanagari, Bengali, Tamil, Telugu, Gujarati, Punjabi, Malayalam

Indic scripts use complex shaping - conjunct consonants combine into ligatures that depend on the consonant cluster and the active font's OpenType tables. A naïve typesetter will produce visually broken Devanagari where conjuncts fail to form. Noto Sans Devanagari, Apple's Devanagari Sangam MN, and a small set of others handle the shaping correctly. We test on the final font, not on a fallback. For technical documents we additionally test on the regional fonts that government regulators expect (e.g., Mangal for some Indian government forms).

Translation changes word count. German averages 30-40% longer than English. Arabic averages 25% longer. Russian averages 15-20% longer. Chinese is typically shorter. A naïve typesetter ships the German version with truncated buttons, overflowing text frames, and broken page breaks; a regulator rejects the document on first review.

Our approach to expansion

• Frame auto-sizing - every text frame in the source InDesign file is set to auto-size to its content. The frame grows; the layout adapts. This is the single biggest source of expansion-related bugs and the simplest to fix.
• Style-sheet expansion budget - we publish a style sheet for each target language showing the maximum allowable expansion before manual reflow. Translators see the budget while translating; if a string overruns, they can request a reword or flag the constraint.
• Reflow rules - we agree per-document reflow rules at scoping. Common: page breaks may shift; section headings may not split; tables may overflow to the next page; figure captions stay with their figure. The rules are documented and applied consistently.
• Page-count change report - at delivery we publish a page-count comparison: source 40 pages, German 48 pages, Arabic 47 pages, Chinese 36 pages. The client knows what they're getting before they open the file.

The pharma case

Pharma patient information leaflets are the high-stakes case. The EMA and MHRA require specific section headings, in a specific order, with no truncation. German expansion routinely pushes a 4-page PIL to 6 pages; the regulator accepts the page-count change as long as section integrity is preserved. We work to the EMA's QRD template for every PIL and proof against the current template version (the template changes; we monitor).

A document that will be printed needs to leave us as print-ready as your printer expects. This is a separate skillset from translation and most translation agencies cannot do it; we have an in-house prepress operator and we deliver to spec.

Print specifications we support

• PDF/X-1a:2001 - the legacy standard, CMYK only, all fonts embedded. Still required by some printers and most newspaper systems.
• PDF/X-4 - modern standard, supports transparency natively, RGB and CMYK, ICC colour profiles. Our default for new work; supported by most modern presses (see the Ghent Workgroup guidance on PDF/X workflows).
• PDF/A - for long-term archive (often required for regulator filings). PDF/A-1b is the conservative choice; PDF/A-2 and -3 add features.
• Marks and bleed - printer's marks, registration marks, colour bars and 3mm bleed by default; configurable per print contract.

Colour management

CMYK conversion needs to know the target press: Fogra 39 / 51 for European coated stocks, GRACoL 2006 for North American, JC2011 for Japanese. We embed the correct ICC profile and proof against soft-proofing if the printer supplies a profile. Pantone spot colours are preserved as spots through to plate-making.

Font embedding and licensing

Every font used must be embedded in the final PDF (PDF/X requires it). Foundry licences vary in what they permit - Monotype, Linotype and Adobe Originals licences are explicit; some commercial fonts forbid embedding and need replacement before export. We audit the font stack and substitute where licensing requires.

Handover to your printer

We deliver the InDesign package (or the print-ready PDF, depending on scope), a Print Spec sheet documenting the bleed, marks, colour profile and stock recommendation, and a soft-proof PDF for visual sign-off. Your printer should be able to plate the file without back-and-forth.

Most of our DTP work is regulated content: pharma, legal, financial, government. Each category has its own deliverable standards and our process is built around them.

Public sector multilingual DTP has its own bar: bilingual and community-language documents for councils, NHS trusts and government agencies must match the English original page for page. Our multilingual typesetting services deliver them print-ready, for London and UK-wide teams alike.

Pharma: PIL, SmPC, IB, ICF

Patient Information Leaflets and Summary of Product Characteristics follow the EMA QRD template; Investigator Brochures follow ICH E6 guidance; Informed Consent Forms follow the IRB or REC template. We work to the current template version (templates revise; we monitor) and deliver against the regulator's submission format (XML for SmPC, PDF for PIL, eCTD for full submissions). Per-span audit trails are mandatory for regulated pharma work; we publish them.

Patent and IP: PCT, EPO, USPTO

Patent filings have format requirements that differ per office. EPO accepts XML and PDF; USPTO requires specific font sizes and margins; PCT submissions have language-specific abstracts. We work to the office's current specification and deliver to that. Drawings are translated separately - figure callouts in the target language with the same numbering scheme.

Legal: court bundles, arbitration packs

UK court submissions need a specific bundle format (single PDF, paginated, indexed, hyperlinked). We rebuild bundles in target language with the same pagination and index structure. For international arbitration we work to the procedural order's specification, which varies per case.

Financial: annual report, prospectus, KID

Annual reports follow each market's listing rules (LSE, AIM, NASDAQ, Euronext) for required sections; prospectuses follow the prospectus regulation; KIDs follow PRIIPs. We coordinate with your financial translation team (often us - see financial translation) to ensure prose, numbers, and layout are in lock-step.

Government: tax, immigration, civil registration

The hardest category for in-place PDF rebuild because forms vary across local offices. We've handled French impots.gouv.fr, German Steuererklärung (multiple Bundesländer), Spanish AEMPS pharmacovigilance forms, Italian Agenzia Entrate, and several UK HMRC forms. Each office's PDF storage convention is documented in our internal library; we know what to expect before we start.