When Translated Text Breaks the Layout: A DTP Specialist on Pre-Translation Engineering
Anyone who has shipped a multilingual document knows the moment: the PDF-to-Word conversion looks clean, the English reads perfectly, and then the translated text lands and the tables split, headings drift away from their paragraphs, and the client wants the file the same day. Viktor Hushchin, founder and lead DTP specialist at Apex DTP Studio, has spent more than a decade in what he calls "the production trenches" of large-scale multilingual DTP and document reconstruction. We asked him three practical questions about where these jobs go wrong and what to do instead.
Same-Day Delivery: Build the Buffer Before Translation
The first scenario is the classic emergency. Hushchin says it happens most often with languages that expand significantly, noting that German, French, and Spanish "frequently expand by 25–35%." The document looks flawless in English, but once the localized text is imported, "tables split awkwardly, text overflows its containers, and headings detach from their body paragraphs."
Under same-day pressure, he warns that "manual page-by-page tweaking is a trap that burns hours." His team's first rule is to engineer room in advance: "If we handle the pre-translation engineering, the best strategy for expandable languages is to reduce the spatial footprint of the layout in the source file (i.e. before translation)." Slightly tightening margins, cell padding, and paragraph spacing creates what he describes as a built-in 20–30% volume buffer, so expanding text simply fills pre-engineered space.
The rest is structural cleanup. Automated converters, he says, "love wrapping callouts and sidebars into floating text boxes that clip text when it expands," so his team strips them and converts them to inline paragraphs with borders or single-cell tables with fluid dimensions. Converted tables usually carry hardcoded column widths and locked row heights; resetting rows to "At least" rather than "Exactly," allowing rows to break across pages, and repeating header rows restores predictable flow.
Rather than shrinking fonts page by page, which he says "ruins readability and client branding," the team adjusts baseline styles globally, tightening space before and after paragraphs and setting line spacing to a multiple of 0.95. Headings get "Keep with next" and "Keep lines together" to eliminate orphans.
What OCR Advice Leaves Out
The standard pitch for OCR tools is simple: scan, export, done. In a 300-page technical manual or regulatory filing, Hushchin says that output hides structural problems. OCR tools often generate automatic numbered lists that introduce "severe structural bugs" — broken hierarchies, wrong numbering symbols, messy tab-based alignment — and tables of contents rendered as flat static text. His rule: "completely strip the OCR-generated numbering and rebuild the multi-level list schemes and dynamic TOC fields from scratch using clean, native Word styles."
Style sheets are the second trap. OCR engines rarely produce a unified stylesheet, instead creating dozens of variations of "Normal" with subtle local overrides. When an LSP imports that file into a CAT tool such as Phrase or Trados, the translator faces "a wall of broken inline tags that slow down translation and destroy Translation Memory (TM) leverage."
He also flags excessive continuous section breaks, which unlink headers and footers and desync pagination the moment text expands, and "pseudo-tables" built from tabs, spaces, or disconnected text boxes rather than a single coherent grid — translating inside them causes columns to misalign across the page.
What LSPs Settle Too Quickly
For agencies working with a new DTP partner, Hushchin says urgency often trumps technical consistency. The most common compromise is accepting a "visual match" instead of document architecture: "If the file is held together with hard returns (Enter), multiple spaces, and floating frames, it will completely break inside the CAT tool." He advises insisting on native styles, section breaks only where page orientation changes, and zero unnecessary tags.
First-time partners also skip what he calls a "CAT Tool Dry Run" — test-importing the first converted pages before greenlighting a 200-page reconstruction. Discovering mid-project that a file carries 15 tags per sentence, he says, "creates massive delays."
Target-script typography is another gap. Agreeing on a flat per-page rate without clarifying non-Latin requirements ignores the specifics of French non-breaking spaces before two-part punctuation, German hyphenation and compound-word overflow, and right-to-left scripts like Arabic and Hebrew, which require mirrored margins, flipped tables, and bidirectional number handling.
Finally, he argues against treating DTP as a final patch: "80% of high-quality DTP happens before translation (Pre-DTP engineering). Spending time cleaning the source file sometimes saves triple the time during post-translation formatting." For teams managing multilingual production at volume, the takeaway is consistent — the layout survives translation when the source file was built to absorb it.