Why is PDF translation so difficult? What are we actually preserving?

In our previous article, “Why preserve a PDF’s layout? A look at how we read,” we looked at reading habits to explain why translating a PDF should leave us with more than translated text. When reading a paper, report, or technical document, we scan headings, find charts, and move between the original and the translation to check details. The original layout helps us remember how these pieces relate to one another.

Technically, though, keeping those relationships intact is not straightforward.

Translating a PDF is not simply replacing one language with another and putting the words back in their original positions. It also means understanding what makes up a page, deciding which text belongs together, and arranging the content again when the translation changes its length.

The real difficulty is that a PDF often tells us where an element is placed, but not necessarily what it belongs to. Which heading governs a paragraph? Which description goes with a chart? Which sentence explains a symbol in an equation? These relationships often have to be inferred from position, styling, and context. Columns, charts, equations, and tables all make that inference harder.

Why a PDF page cannot simply be read as a stream of text

When editing a document, we usually know that a heading is a heading, a paragraph is a paragraph, and a table entry belongs to a particular column. A PDF is closer to the final appearance of the page: text, lines, images, and white space are positioned on it, but may not come with clear structural information.

A single paragraph may be split into many separate text blocks. Text inside a chart may be stored separately from its graphics. A table may be no more than a collection of lines and numbers, without explicit rows and columns. Scanned PDFs add another layer: the visible page is an image, so text, tables, and equations first have to be recognized within that image.

Before translation, several questions therefore need answering:

Which text belongs to the same paragraph?
Which heading applies to the content below it?
In what order should two columns be read?
Which figure or table does a description belong to?
How should headers and footers be distinguished from the body?

Without understanding these relationships first, extracting text, translating it block by block, and placing it back in sequence can produce a page where every sentence has been translated, but readers no longer know where to begin.

The first step is therefore not replacing words, but trying to understand the page’s structure. Technically, this is more like reconstructing relationships between headings, paragraphs, figures, and descriptions on a finished page than reading a simple string of text.

With two columns, reading order is the real challenge

Papers and technical reports often use two columns. What we want to preserve is not two vertical areas, but the reader’s path through the page: which column comes first, where a heading belongs, and when a footnote should be read.

A person may quickly see that the left column comes before the right. For a processing system, however, the positions of text on a page do not automatically define its reading order.

A paragraph may be broken into many lines, each recognized as a separate text block. Following coordinates or extraction order alone can cause content to jump into the right column before the left is finished, put a heading in the wrong place, insert a footnote into the body, or mistake a figure spanning both columns for part of just one.

Technically, the system must handle page regions, text-block ordering, and content that interrupts the normal flow together:

Identify the boundaries between columns.
Distinguish headings, body text, footnotes, headers, and footers.
Recover the sequence between text blocks.
Recalculate line breaks within the available column width after translation.
Check whether readers can still follow the original order.

If the translation is longer, it may no longer fit inside its original text region. Forcing every line to keep its old position can cause overlapping text or excessive gaps. Good reconstruction is not about keeping every character at its original coordinates; it is about preserving the reading order that the columns provide.

Charts are easy to underestimate in PDF translation. What needs preserving is not a picture that looks roughly the same, but the correspondence between graphics, data, legends, captions, and the main text.

To a reader, a figure and nearby text naturally belong to the same argument. Inside a PDF, however, they may be independent objects, sometimes even on different content layers.

The body can be fully translated while chart titles, axes, legends, and annotations remain unprocessed, leaving readers unable to follow the author’s point. Conversely, translating only the words inside a chart without preserving their relationship to the body and caption also separates information that belongs together.

A chart usually contains several layers of information:

A title that tells us what it is about.
Axes and units that explain how to interpret the numbers.
A legend that explains colors, lines, or symbols.
Annotations that highlight a result or change.
Captions and references in the body that add conditions and explanations.

These need to be considered together. Technically, the system must establish their relationships without relying on proximity alone:

A caption may sit below a figure, or appear on the next page after a page break.
In a two-column layout, the nearest paragraph is not necessarily the figure’s description.
The body may refer to a distant figure with a phrase such as “see Figure 2.”
Words inside a chart may be extractable text, or already merged into an image.
Axes, legends, and data labels need translation, while numbers and data relationships must remain unchanged.

Translation should preserve the relationships between data, graphics, and explanations as far as possible, rather than translating only the sentences that can be extracted. In other words, recognizing “there is text here” is not enough; the system also needs to determine the role that text plays in the chart.

That is why checking whether the words were translated cannot, by itself, tell us whether a chart has been preserved well. We also need to check that legends still match, units have not disappeared, captions can still be found, and “Figure 2” in the body really points to that figure. One broken relationship can change what readers understand, even when the chart is still present.

The difficulty with equations lies in the relationships around them

An equation usually does not need translation. What needs preserving is its relationship to the surrounding text: explanations of variables, references to equation numbers, and the conditions stated before and after it.

A variable may be explained in the following paragraph, an equation number may be cited in the body, and a nearby condition may determine whether a conclusion holds. Keeping the equation while losing its connection to variable definitions, numbering, or context still makes it hard to use.

Technically, equations can also exist in different forms. Some combine text characters and vector lines; others are already images, without the mathematical structure from the original editor. During extraction, superscripts, subscripts, radicals, and Greek letters may be split apart or confused. During layout, an equation cannot be wrapped arbitrarily like an ordinary sentence. Equations, numbers, and references in the body must also stay aligned in meaning: an ordering or positioning error must not make readers associate “Equation (3)” with a different equation.

At a minimum, equation reconstruction needs to check:

Whether symbols, superscripts, subscripts, and special characters are intact.
Whether equation numbering agrees with references in the body.
Whether variable definitions remain near the relevant content.
Whether equations are still readable after line breaks.
Whether the surrounding explanations have been split incorrectly.

For papers and technical documents, confirming that an equation still appears on the page is only the most basic check. Its relationship to the text before and after it matters just as much.

One misplaced table entry can change what a number means

Preserving a table is not simply preserving borders and lines. It means keeping the relationships between rows, columns, headers, units, notes, and numbers. A number has its full meaning only when it sits with the correct row, column, heading, and unit.

Real documents may contain merged cells, headers repeated across pages, borderless columns, or tables made from text aligned with spaces. After translation, longer text in one cell can affect the width of an entire column. Putting it back at its original coordinates may make it overflow, obscure the next column, or appear to place a number in another row.

What table reconstruction must preserve, then, is the row-and-column structure, header hierarchy, units, and notes—not just lines drawn in the same positions.

When a translation grows, the page needs a new balance

Even with the page structure correctly identified, another practical problem remains: languages need different amounts of space to express the same idea. What matters here is not each character’s original coordinates, but clear spatial relationships between headings, paragraphs, charts, and equations.

An English paragraph translated into Chinese may become shorter, or grow because of terminology, parentheses, and explanations. Changing languages also changes where words can break, how punctuation is arranged, and how wide the font is. All of these affect the finished page.

This can change:

Line breaks within two-column text.
Whether a heading needs two lines.
The space available beside a chart.
Whether table text extends beyond its cell.
Whether the original page regions can hold the complete translation.

The translated layout therefore cannot just paste new text into the old boxes. It has to balance structural similarity with comfortable reading.

How we approach preserving these relationships

At iSomor, layout reconstruction is part of translation, not decoration added at the end. Current processing is based on PDFs with extractable text, connecting page-layout recognition, paragraph organization, translation, and translated-text layout. The stages below explain both what we work on and how we assess whether the result is useful. They do not mean that every complex relationship can already be recognized and checked automatically.

Start by identifying meaningful content objects

Page parsing combines text positions and layout regions to distinguish body text, headings, charts, equations, and other content as far as possible, then organizes the paragraphs that need translation. The aim is not to cut the page into ever smaller pieces, but to avoid splitting text that belongs together or mixing text from separate regions.

Tables provide a concrete example. Our implementation uses cell-region information to assist subsequent paragraph grouping: lines in the same cell should, where possible, be understood together, while content in different cells should not be mixed. This does not mean every table has been accurately reconstructed. Borderless tables, complex headers, and multiple paragraphs within a cell can still produce grouping errors and require further checking.

Recognizing a figure is not enough. A useful result also depends on whether its caption, legend, and references in the body still correspond to it. The same applies to equations: their numbers and variable definitions must not become disconnected.

This is first a reconstruction goal, not a promise that the system understands every reference. In real files, preserving graphics, numbering, and the positions of nearby text helps readers cross-check. But a page that looks complete is not proof that captions across page breaks, distant references, or text embedded in images have been handled correctly.

Preserve necessary context within paragraphs

Current translation operates on paragraphs rather than treating each line as an independent sentence. Organizing paragraphs as accurately as possible reduces the loss of context caused by splitting a sentence.

Paragraph grouping does not, however, automatically guarantee consistent terminology throughout a document. The same term may still be translated differently in a heading, the body, a legend, or a table, particularly when these occupy separate regions. We still recommend checking important terminology and conclusions against the original rather than treating a completed translation as a completed document-wide consistency check.

Recalculate space for the translated text

When text length changes, line breaks and text layout need adjusting within the available regions while preserving charts, equations, and other content as far as possible. The difficulty is that fitting one paragraph does not guarantee that it will not conflict with neighboring regions.

A heading that now takes two lines may crowd the text below. A longer caption may exceed its available space. Translated table text may collide with the next column. Re-layout therefore means finding a readable arrangement within mutually constrained regions, not pasting characters back at their original coordinates. We do not claim automatic column-width reconstruction, moving figures across pages, or repagination as outcomes available for every file.

The result will not necessarily match the original pixel for pixel. More importantly, readers should still be able to distinguish headings from the body, find a chart’s explanation, and follow the original argument.

Return to the original to check content and layout

A tidy page is not necessarily a correct page. Review needs to consider three kinds of problems separately: missing or repeated content, mismatched relationships, and overlap, clipping, or incorrect order. These are dimensions for evaluating the result, not a claim that the tool has already performed every content and visual check automatically.

A chart may be fully visible while its connection to its caption is unclear. An equation may be present with a misplaced superscript or subscript. A table may look aligned while a number has landed in the adjacent column. Finding these problems requires comparing content and structure, not just inspecting a final screenshot.

For numbers, terminology, equations, and conclusions, the original remains an important reference. Preserving layout can make searching and checking easier, but cannot replace readers’ judgment about key information.

We want a document you can keep reading, not an identical picture

“Preserving the layout” can sound as though every character and line must remain in exactly the same position. Once the language has changed, that is not always a reasonable goal.

Shrinking a translation to keep the same line count, or squeezing paragraphs together, may make a page resemble the original more closely while making it harder to read. Conversely, modest changes to line breaks, font size, or line spacing within the available area can help readers continue, provided the relationships between headings, charts, equations, and explanations remain clear.

We therefore care more about several practical questions:

Has the content been preserved in full?
Is the reading order clear?
Do charts, equations, and the body still correspond?
Can readers return to the original when they need to check something?
Is the page still suitable for actual reading?

This is the problem iSomor hopes to address. We are not trying to turn a PDF into a string of translated sentences, but to keep it usable as a document people can read, search through, and work with.

Complex files still need checking

PDFs vary widely in their source and how they were made. iSomor currently handles PDFs containing extractable text; OCR for full-page scanned images is not currently available. Even in text-based PDFs, complex nested tables, unusual fonts, and text merged into images may exceed the limits of automated processing.

After translation, it is therefore still worth checking important numbers, equations, charts, and conclusions in a paper against the original. We do not treat a neat layout as proof that all the content is correct.

For us, the point of the technical work is not to pass complexity on to readers, but to handle as much as possible of what would interrupt their reading beforehand. Every bit of reorganizing or searching for a matching passage they no longer need to do gives them more room to focus on the document itself.