Regulated Document DTP & PDF Rebuild

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.

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.

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.

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.

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 — Tajawal, 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.

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.

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 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.

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 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 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 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 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, Adobe'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).

• 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.

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).

• 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.
• 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.

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.

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.

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.

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 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.

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.

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.

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.