A translated PDF can look tidy on screen and still send a screen reader through its columns in the wrong order. That gap between what a person sees and what the file contains is why a layout check needs more than a quick glance at the pages.
A reliable translated PDF layout check asks two separate questions: does the page look right, and does the file behave right when someone copies, extracts, or listens to its text? The first question catches visible problems such as clipped lines and broken tables. The second catches sequence and structure problems that a screenshot cannot show.
This guide gives you a practical review workflow for text PDFs, complex pages, forms, and right-to-left translations. You can use it for a translator’s final pass, an agency QA handoff, or a check before a translated document goes to a client.
What a translated PDF layout check actually covers¶
A translated PDF layout check is a review of both the rendered page and the document’s underlying text structure. The rendered page is what a reader sees. The underlying structure affects what happens when someone selects text, copies it, extracts it, or navigates it with assistive technology.
Those two layers can disagree. A heading may sit in the right place visually but appear after a paragraph when extracted. A two-column page may look like two clear columns yet have no structure that tells a reading tool which column comes first. A page can also look acceptable at normal zoom while a letter, number, or accent has been replaced during recognition.
PDFs don’t store content in the same way as a word-processing file. A PDF page can consist of text placed at coordinates rather than paragraphs and tables with an obvious reading sequence. Translation and document reconstruction can therefore introduce layout changes even when the translated wording is correct. The reviewer has to check the result as a page and as a sequence of information.
The distinction matters most when the file includes columns, tables, footnotes, sidebars, graphics, or form fields. W3C says that complex layouts with these elements may not convert to tagged PDF in the correct reading order and may need repair (W3C’s PDF3 technique). Tags are structural labels inside a PDF. They can identify items such as headings, paragraphs, and tables, and the order of those tags plays a key part in how a tagged PDF is read.
A visual comparison remains useful, but it answers only part of the question. Adobe Acrobat’s document comparison feature can help you identify differences between two PDF versions. Treat its result as a prompt for review, not a verdict about translation accuracy or reading order.
As W3C explains in PDF3: “When the reading order is not correct, keyboard and assistive technology users may not be able to understand the content.”
That warning is about more than accessibility in the narrow sense. A scrambled sequence can make a procedure, contract clause, table, or set of instructions hard to follow for anyone who copies text into another tool or works through the file without relying on the visual page.
Keep the original PDF available while reviewing the translated file. When an editable authoring file exists, a forum respondent in an RWS Community discussion recommends working from that source instead of processing the PDF directly. That is a workflow preference, not a universal rule, but it gives the translator a clearer structure to work with when the source is available.
For more on preserving columns during document translation, see how to translate multi-column layouts without reflow chaos. A text-focused workflow can also help explain why a file that looks visually similar still needs a separate text and structure pass.
A practical page-by-page review workflow¶
A page-by-page review gives the team a repeatable way to catch visible defects without forgetting text order. Start with a clean reference copy of the source and the final translated PDF. Review them side by side, then test the translated file on its own.
1. Confirm that the right files are being compared¶
Check the filenames, language direction, and document version before you start marking differences. A layout review can be precise and still be useless if the reviewer has an outdated source or a draft translation open.
Match corresponding pages rather than assuming that page one in the source must match page one in the target. Translated wording can expand or contract, and page breaks can move. If a paragraph from the source’s first page appears on the next translated page, that is a change to inspect, not automatic proof of an error.
A useful review copy can include page numbers and a simple status column: pass, fix, or query. The status should identify what needs action. “Table broken” is less useful than “right-hand column clips the final line in the lower table.”
2. Compare page geometry and visual hierarchy¶
Scan each translated page for the main content regions: title, headings, paragraphs, tables, callouts, footnotes, headers, and footers. Check whether the eye still finds the same hierarchy and whether anything has moved into a confusing position.
Look for text that touches or crosses a page edge, disappears behind an image, overlaps another line, or sits too close to a rule. Inspect both the top and bottom of each page. A footer may collide with a longer translated paragraph, while a heading may be stranded at the bottom with its explanation on the next page.
Page flow deserves its own note. A practitioner in an RWS Community forum discussion described text from the first page moving to the second, along with poor spacing in the generated translation. That report is an individual experience rather than a standard, but it points to a concrete check: compare where sections begin and end, not only whether every page has the same number.
3. Check line wrapping, spacing, and overflow¶
Translation changes text length, so line wrapping will often differ from the source. The goal isn’t to reproduce every source line break. The goal is to keep the translated text readable, complete, and clearly connected to the right visual element.
Inspect headings that wrap onto extra lines, paragraph lines with unusually large gaps, and lists whose bullets no longer align with their text. Check whether text has been squeezed into a small area or made so loose that the relationship between a label and its value becomes unclear.
Overflow isn’t limited to a single clipped line. A longer paragraph can push a table down, shift a footnote away from its marker, or cause a section to continue on another page without a clear heading. Trace the content into the next page before marking a layout issue resolved.
4. Inspect tables, labels, and page furniture¶
Tables need a structure check as well as a visual one. Follow each row from label to value, confirm that column headings remain attached to the right columns, and check whether translated text wraps inside cells without hiding the next row.
Compare merged cells, repeated headings, border lines, and alignment. A table can look neat while pairing a translated value with the wrong label. The reviewer should read across and down the table in the intended order rather than judging spacing alone.
Check repeating elements too. Page numbers, document titles, dates, section labels, footnote markers, and captions can be duplicated, omitted, or left in the source language. A single footer defect may appear across the whole file, so look for patterns as well as page-specific issues.
5. Verify the text, characters, and page sequence¶
Select and copy text from representative pages, then paste it into a plain-text editor or another place where sequence is easy to inspect. Compare the extracted wording with the visible page. Watch for missing words, duplicated text, strange character substitutions, and content that appears in an unexpected order.
A text extraction pass can reveal a source problem that a visual target review misses. In the RWS discussion, an English-to-Greek PDF workflow produced source recognition errors, including characters being replaced by other characters. The same discussion describes damaged segmentation and spacing in the generated translation. Those are reported practitioner observations, not evidence that every PDF conversion behaves the same way, but they show why reviewers should inspect source-text fidelity as well as the final page.
For a tagged PDF, use a screen reader or read-aloud tool to check the reading order on pages with columns or complex structures. W3C lists listening to the document as a way to test sequence, and explains that the order of tags in the structure tree primarily determines reading order in a tagged PDF (PDF3). A page’s visual layout alone can’t confirm that sequence.
6. Check fonts, links, and interactive behaviour¶
Read every special character closely: accented letters, symbols, punctuation, and glyphs from the target script. A font can lack the character needed by the translation, leaving a blank box, an incorrect substitute, or an inconsistent-looking letter.
The RWS forum discussion includes a respondent’s advice to check whether the target-language font covers the required characters. Treat that as a practical QA point, not a formal specification. When a glyph looks suspicious, compare it with the same character elsewhere in the file and copy it into plain text to check whether the extracted character is also wrong.
Click hyperlinks and inspect interactive elements if the PDF contains them. W3C says that interactive PDFs need a focus or tab-order check alongside reading order. Use the Tab key to move through focusable items and verify that the sequence follows the document’s intended logic (W3C PDF3).
Adobe Acrobat Pro’s Preflight tool documentation describes a way to analyze PDF files. A preflight result can help identify technical properties to investigate, but it doesn’t tell you whether a translated sentence is accurate or whether a table’s meaning survived translation.
7. Record defects so someone else can fix them¶
A QA note should tell the person fixing the document where the problem is, what the reviewer sees, and what outcome is needed. “Page looks off” leaves too much guesswork.
Use a short defect record with the page or section, element, observed problem, expected behaviour, and status. Keep translation questions separate from layout fixes. A missing source word may need a language decision; a clipped line may need a layout adjustment; a wrong reading sequence may need structural repair.
A compact handoff can look like this:
| Location | Check | Finding | Next action |
|---|---|---|---|
| Page or section | Table, paragraph, glyph, or reading order | Describe the visible or extracted-text issue | Correct, query, or retest |
The record becomes especially useful when the repair affects more than one page. After a change to font size, table width, or page flow, recheck the nearby content instead of assuming the fix stayed local.
When a deeper review is needed, and when it isn’t¶
Not every translated PDF needs the same level of inspection. A straightforward one-page notice with ordinary paragraphs can be reviewed differently from a form, a two-column report, or a document with mixed RTL and Latin text.
Spend extra time on complex or high-impact pages¶
Give extra attention to pages with two or more columns, tables, sidebars, footnotes, graphics, form fields, or a dense mix of labels and instructions. These elements can have an order that isn’t obvious from their position on the page. W3C specifically identifies complex layouts containing graphics, tables, footnotes, sidebars, and form fields as cases where correct tagged reading order may need repair (PDF3).
Forms need more than a visual pass. Confirm that each field appears in the logical sequence relative to the surrounding text. W3C notes that fields can be missing from tagged content or placed in the wrong position within the PDF content. A field that looks correctly placed may still be encountered at the wrong point by a keyboard or assistive-technology user.
Interactive files also need a tab-order check. W3C’s PDF3 test procedure includes moving through focusable items with the Tab key. The quoted rule is direct:
“The tab order must reflect the logical order of the document.” - W3C, PDF3 technique
For an interactive form, that means following the controls in sequence and asking whether each one appears where a reader expects it. A visually accurate form isn’t ready for handoff if focus jumps between fields in a confusing order.
A lighter pass can suit simple, non-interactive files¶
A short, single-column document with ordinary paragraphs and no form fields may not need the same structural investigation as a complex report. A careful visual comparison and a check that the text copies in the intended sequence may be enough for a layout-focused review.
“Lighter” doesn’t mean skipping the basics. Confirm that every paragraph is present, the pages flow sensibly, the characters render, and the translated text is attached to the correct headings and labels. If the copy-and-paste result is scrambled, or if an intended reader uses assistive technology, move to a deeper reading-order check.
W3C describes PDF3 as an informative technique for tagged PDFs, not a mandatory single method. The technique page says that its examples aren’t required if the normative WCAG requirements are met by another method (W3C PDF3). In practical terms, use the technique to help find and test problems; don’t treat one tool or one procedure as the only possible way to meet an accessibility requirement.
A related decision is whether the PDF is the best working source. When the original editable file is available, working from it can preserve clearer document structure. When the PDF is the only source, the review should pay close attention to recognition and reconstruction. For a fuller comparison of those workflows, see translating PDFs and scans with AI-OCR: what works and what doesn’t and how to translate a PDF without losing formatting or layout.
RTL pages, common failures, and how to prevent repeat work¶
Right-to-left translations need a focused pass because a sentence can combine RTL text with left-to-right numbers, dates, punctuation, or embedded Latin names. The page may look mostly correct while the order of one mixed-direction string is hard to read or ambiguous.
Review mixed-direction text as a complete unit¶
The Unicode Bidirectional Algorithm describes how directionality affects the display of right-to-left scripts such as Arabic and Hebrew. Unicode notes that mixed-direction strings can include left-to-right digits and embedded English words, and that the visual order can be ambiguous when horizontal text direction is mixed (Unicode Bidirectional Algorithm).
Check each date, amount, identifier, phone number, and Latin name in its full context. Don’t inspect only the Arabic or Hebrew words around it. Confirm that punctuation appears with the intended part of the string, that digits remain in the right sequence, and that an embedded Latin name hasn’t shifted to an unexpected visual position.
As the Unicode Consortium explains in UAX #9: “When working with bidirectional text, the characters are still interpreted in logical order - only the display is affected.”
The distinction matters during copy-and-paste review. Unicode says that bidirectional text is interpreted in logical order while display order depends on character directionality. Compare the displayed string with the copied or extracted sequence whenever the order of numbers, names, or punctuation matters.
Unicode also defines directional formatting characters that can affect display order when implicit bidirectional ordering isn’t enough. Their presence calls for targeted review of the affected mixed-direction passage. Unicode says those formatting characters affect display ordering and should otherwise be ignored for text comparison, word breaks, parsing, and numeric analysis (UAX #9). Don’t mistake a display-control character for visible content or let it hide a sequence error.
For practical RTL troubleshooting, see how to fix Arabic RTL layout and formatting issues. A language specialist can assess the wording, while a layout reviewer checks direction, placement, and sequence in the final file.
Common defects and their actual causes¶
A translated PDF can fail in several ways at once. Naming the failure helps the team choose the right repair rather than adjusting the page at random.
| Symptom | What to inspect | Why a visual glance may miss it |
|---|---|---|
| A paragraph is clipped | Text box size, line wrapping, and the next page | The first lines may look fine while the final line disappears |
| A table looks aligned but reads incorrectly | Row and column sequence, extracted text, and tags | The visual grid doesn’t prove the underlying reading order |
| A symbol or letter appears wrong | Font coverage and copied text | A similar-looking glyph can conceal character substitution |
| A two-column page reads across both columns | Extracted text, tags, or screen-reader output | The visible columns can look clear while the reading sequence is not |
| A form field is skipped or reached too early | Tagged content and tab order | Field placement on the page doesn’t prove its place in the sequence |
| An RTL date looks reversed or detached | Full mixed-direction string and extracted sequence | The visual position of digits and punctuation can be ambiguous |
W3C specifically warns that an untagged multi-column PDF can be read from top to bottom across both columns as though they formed one column. The page can still appear to invite column-by-column reading. That mismatch is exactly why a visual page scan and a text or screen-reader pass need to be separate checks (W3C PDF3).
A forum practitioner described a particularly frustrating combination: source recognition errors, text moving to another page, damaged segmentation, and poor spacing in the generated translation (RWS Community discussion). The practical lesson isn’t that every conversion will fail in those ways. The lesson is that reviewers should check both the recognized source and the target layout, especially when the PDF began as a scan or had unusual text encoding.
Prevent the same problem from returning¶
When a defect appears, identify which layer caused it before making a correction. A misplaced visual block may need a layout change. A wrong copied character may point to source recognition or font coverage. A scrambled sequence may require tag or content-order repair rather than a larger text box.
Retest the repaired page and the pages around it. A font change can affect line wrapping elsewhere; widening a table can shift a paragraph or footer; correcting a page break can move a heading. The final check should revisit the original defect and any content that the repair could have displaced.
Use a preflight tool when the question concerns technical PDF properties, and a visual comparison when the question concerns differences between versions. Use text extraction or a screen reader when the question concerns sequence. Use a language reviewer when the question concerns meaning. Each method answers a different question, so one successful test shouldn’t stand in for the others.
FAQ¶
How do you check the layout of a translated PDF?¶
Review every page against the source, then check text extraction or reading order, font and glyph rendering, tables, page flow, and any interactive fields. A visual pass can’t prove that a tagged PDF’s logical order is correct; W3C’s PDF3 technique explains why reading order needs a separate check (W3C PDF3).
What should you inspect after translating a PDF?¶
Inspect completeness, line breaks, clipping, spacing, page breaks, headings, tables, footnotes, images, glyphs, and extracted text order. Check links, form fields, and tab order when the document is interactive. Give columns and pages with sidebars or footnotes extra attention because their reading sequence may not match their visual arrangement.
How can I compare a translated PDF with the original?¶
Place corresponding pages side by side and compare content position, line wrapping, tables, headings, headers, footers, and page flow. Adobe Acrobat provides a document comparison feature for PDF versions (Adobe Acrobat documentation); use its output to guide review, then check the translation and text sequence yourself.
How do I check reading order and text extraction in a translated PDF?¶
Copy text from the PDF into a plain-text editor or listen to it with a screen reader or read-aloud tool. Compare the resulting sequence with the intended reading order, especially on multi-column pages. W3C says that a tagged PDF’s reading order primarily follows the tag structure, not visual appearance alone (W3C PDF3).
What layout problems should I check in a right-to-left translated PDF?¶
Check paragraph and table direction, then review numbers, dates, punctuation, and embedded Latin names as complete strings. Compare the visual display with copied or extracted text because Unicode’s bidirectional rules distinguish logical character order from display order (Unicode UAX #9).