Translate Like a Pro | 11810 — MuPDF mutool draw CLI: Multilingual PDF Rendering, Page Images, DPI and Visual Regression QA

A translated PDF can pass a text-extraction test and still be impossible to read comfortably. A Vietnamese accent may collide with the line above, an Arabic paragraph may render with broken joins, or a German heading may overflow a narrow page element. MuPDF’s mutool draw command lets publishers render PDF pages into images so that these visible defects can be investigated systematically.

This mutool draw CLI guide shows how to produce page images for multilingual PDF visual quality assurance, choose resolution, select pages, compare exports and investigate clipping, font substitution, rotation, color and script rendering. It is designed for documentation teams, translators, print-production specialists, accessibility reviewers and developers who want repeatable evidence of what a page actually looks like.

A rendered image is only one part of a trustworthy translation review. It cannot establish that wording is accurate, that copied text has correct Unicode, that a screen reader encounters meaningful reading order or that a font is legally licensed. The most reliable workflow pairs image inspection with language editing, source-level corrections, text-extraction checks and a documented approval process.

Quick answers for mutool draw visual QA

Use \mutool draw -o page-%03d.png "translated-manual.pdf"\ to render pages to numbered PNG files.
Add \-r 144\ or another tested resolution to make small marks and fine typography easier to inspect.
Specify a page selection, such as \1-3,8,12\, when investigating particular pages.
Keep resolution, font environment, renderer version and page-box settings consistent in before-and-after comparisons.
Review authentic target-language text: long words, mixed scripts, tables, captions, numerals, diacritics and directionality.
Do not confuse a visually correct screenshot with proof that a document is semantically correct, accessible or searchable.

What rendering a PDF actually tests

The practical job of a renderer is to turn page instructions into visible pixels or another presentation form. A PDF can contain font resources, shapes, images, colors, annotations and many other objects. Rendering interprets the drawing instructions for the selected page and produces the view that people can inspect. This is useful because many translation problems become visible only after layout and typography have been applied.

Think of the workflow as three layers. The first is meaning: are the translated sentences accurate and appropriate for the target audience? The second is encoded representation: are the intended characters, order and metadata preserved in the final file? The third is visible presentation: are the words actually legible, placed correctly and easy to associate with their captions, figures and warnings? Mutool draw is primarily a tool for the third layer.

Even within visual presentation, there is no single perfect screenshot. The renderer uses settings for output resolution, graphics processing and available resources. Another PDF viewer or operating system may produce small differences. The purpose of a test is to establish consistent conditions and investigate meaningful deviations, not to claim that one image captures every possible reading environment.

A good result is specific. You should be able to say which page was rendered, at what resolution, using which command and which symptom was checked. ‘The file looks fine’ is not a useful release record for a fifty-page multilingual safety manual.

Install, version and first safe render

MuPDF distributes mutool with several commands. Mutool draw is its rendering and text-conversion subcommand. Check your installed build’s help and version information because options can change across releases. The official documentation describes rendering to common image formats and other outputs; this guide focuses on page images because they support visual comparison of translated documents.

The simplest command specifies the output filename. Include a page-number pattern for multipage output. Without a distinct filename for each page, a batch workflow can be hard to manage or may not behave as expected. Use a diagnostic output directory and preserve the original PDF rather than writing over approved files.

\\\ mutool draw -o "page-%03d.png" "manual-es.pdf" mutool draw -r 144 -o "check-%03d.png" "manual-es.pdf" 2-5 mutool draw -r 200 -o "cover.png" "manual-es.pdf" 1 \\\

The %03d placeholder creates zero-padded page numbers in output filenames. The -r option sets rendering resolution in dots per inch; 72 dpi is the documented default. The final positional argument can select pages or ranges. Because the accepted syntax and defaults matter to reproducibility, save the exact command alongside the rendered images.

Use a maintained installation and treat unfamiliar PDFs as potentially untrusted input. Keep confidential documents and their screenshots in approved storage. A rendered PNG can reveal the complete text and may be easier to share inadvertently than a protected PDF. Do not send sensitive pages to an unapproved external visual-comparison service.

Why resolution changes what you can see

At low resolution, small accents and fine marks may blend into surrounding pixels. At higher resolution, reviewers can inspect diacritics, punctuation, thin lines and letter spacing with greater confidence. However, increasing resolution does not improve the actual source text or repair a missing glyph. It creates a more detailed image of whatever the renderer draws.

Choose a resolution based on the purpose. A quick overview can use modest DPI to reveal gross overflow and missing pages. A typography investigation may use higher DPI to inspect marks or baseline positioning. A print-focused review may also require checking the physical document at intended output size. Do not infer that a page is readable merely because it looks crisp at an unrealistic zoom level.

Comparisons are reliable only when the settings match. A before image rendered at 72 dpi and an after image rendered at 300 dpi will have different dimensions and edge details. Pixel comparison will flag large changes that have nothing to do with translation. Keep resolution and other settings constant when assessing a revision.

High-resolution rendering consumes more memory, storage and processing time. For long manuals, start with representative pages or pages changed by the latest translation. Reserve expensive whole-document passes for a defined release requirement. Quality assurance should balance thoroughness with a clearly described risk model.

Page selection and why complete coverage still matters

Mutool draw can take a comma-separated selection of page ranges. This is helpful when a translator reports a specific issue on page 47 or when the layout team changes only one chapter. You can render the affected pages first, obtain useful screenshots and shorten the debugging cycle.

A page label printed in the document may not match its PDF page position. A booklet may have an unnumbered cover, several front-matter pages or Roman numerals. Confirm the actual PDF position before rendering a range. If your issue tracker says ‘page 11’, include enough context to make the page unambiguous.

After investigating a focused problem, expand the check. A change to a template’s font or paragraph style can affect other pages. A longer French translation may push the next section to an unexpected page. A page-numbered selection is efficient for diagnosis but should not become the only criterion for accepting the full release.

A practical approach uses three layers of sampling: the exact reported page, neighboring pages and representative pages throughout the document. Add all pages for high-risk or automated checks where feasible. Record why certain pages received closer attention. That turns sampling from an informal habit into a repeatable review method.

Naming, storing and comparing rendered pages

File naming is part of visual QA. Use a naming convention that identifies locale, revision, page and output settings without exposing unnecessary confidential material. For instance, a project might store versioned folders for English and Arabic editions, each containing page-001.png and so on. The file name should let a reviewer connect an image back to the exact PDF.

Never compare two images merely because their filenames match. Check that they came from the intended versions, that page order has not shifted and that both renders used the same settings. If a translation adds a page, a naïve comparison of page 20 against page 20 may compare different content. Align content logically before interpreting differences.

Simple visual side-by-side review is often more useful than a raw pixel diff. A one-pixel anti-aliasing change may create thousands of changed pixels without affecting legibility. A missing negative sign is visually small but semantically important. Automated image differences can prioritize pages for review, but a knowledgeable person must interpret the differences.

Maintain a small evidence packet for every serious issue: source PDF revision, command, rendered images, expected appearance and correction decision. Avoid filling the packet with dozens of near-identical screenshots. Select the ones that explain the failure and demonstrate the corrected result.

Distinguishing source-language errors from display errors

Suppose a Spanish notice displays an unexpected symbol where a word should contain ñ. Before adjusting font settings, check the approved source text. If the translator submitted the correct Unicode sequence, examine the PDF’s embedding and shaping path. If the source itself contains the wrong character, a rendering test cannot fix it. The issue belongs to translation or editorial review.

The distinction becomes even more important with scripts a reviewer cannot read. A designer might see only unfamiliar glyphs and assume the sentence is correct because it fits. A fluent reviewer might see a perfectly formed but wrong word. Therefore the render should be paired with a language-approved reference, ideally from the editable source.

Avoid accepting ‘looks similar’ as a replacement for correct characters. In some scripts, small changes to dots, strokes or diacritics create different letters or words. The visible appearance can help locate the issue, but Unicode comparison and language expertise are required to determine what the text should say.

When the correct text is present but the drawn shapes differ, record the specific glyph or cluster, the font involved and the surrounding words. Then test a source-level correction and render again. Change one variable at a time so the team can identify what solved the defect.

Arabic joining and bidirectional visual tests

Arabic text gives a compelling example of why a page image is necessary. Letters may join depending on their neighbors, combining marks must be placed sensibly and numbers or web addresses may interact with right-to-left layout. A text extraction can preserve the correct Unicode sequence while the rendered appearance remains unreadable.

Test natural phrases containing joining forms, punctuation, Arabic and Latin digits, parentheses and any URLs used in the actual document. Compare the rendered phrase with a reference approved by a competent Arabic reader. Check the whole line because a word may render correctly alone while directionality becomes confusing when it sits beside a telephone number.

If a punctuation mark appears on the wrong side of a sentence, do not assume it is a font failure. The problem may come from paragraph direction, segmentation or a bidirectional formatting decision in the authoring application. A different font may have no effect. Use the screenshot to describe the symptom, then inspect source structure and Unicode order separately.

In publication review, ask whether the reader can act on the instruction. A safety leaflet that contains a phone number must allow readers to identify and use that number without ambiguity. Visual QA is successful only when it protects real communication, not just decorative typography.

Hebrew typography and marks in dense documents

Hebrew text may be set with or without vowel points depending on audience and genre. When marks are present, cramped line height and font choice can reduce readability. A high-resolution render helps reveal collisions or missing details, especially in educational or religious material where small marks may be meaningful.

Do not judge the text by the presence of a font family alone. A font may contain glyphs but position certain marks poorly in a given layout. Test actual words from the approved document and examine how they behave in headings, footnotes and narrow table cells. Preserve punctuation and bidirectional formatting around Latin references.

Some files may render correctly in MuPDF but differently in another viewer. That discrepancy is valuable evidence. Record both environments rather than treating either one as the sole authority. If publication targets a known reader environment, include that environment in acceptance testing.

A reviewer who does not read Hebrew can document overlap, clipping and broken geometry. But language-specific correctness should be approved by a qualified person. The same division of responsibility applies throughout multilingual publishing.

Indic shaping, conjuncts and combining marks

Devanagari, Bengali, Tamil and other writing systems can depend on font shaping and careful placement of marks. If a Hindi training booklet shows detached vowel signs or an unusual consonant cluster, the problem may not be visible in a plain-text comparison. A rendered page makes the symptom concrete.

Use realistic text containing the kinds of clusters and marks that appear in the publication. Include large headings, body copy and small labels. Different text sizes and spacing can expose different defects. A glyph may appear acceptable at body size while a small caption becomes unreadable or a bold heading loses necessary details.

Pair image inspection with the approved Unicode text. If the extracted text differs, investigate mapping or encoding. If the extracted characters match but the image is wrong, investigate fonts, shaping and layout. These are different classes of defect, and the distinction prevents inappropriate edits to the translation.

Do not use a synthetic script sample as the only test. Real sentences include combinations of punctuation, spacing and typographic hierarchy that a short alphabet display cannot replicate. Translation quality ultimately depends on whether real readers can understand real material.

Chinese, Japanese and Korean font differences

A CJK PDF may contain correct characters but use a font whose regional glyph forms are unsuitable for its audience. The difference can be subtle to a nonreader. Chinese for mainland audiences, Traditional Chinese for Taiwan or Hong Kong, and Japanese typography may use different preferred glyph appearances and punctuation conventions. A generic ‘CJK supported’ result is not enough.

Render representative pages and review them with a reader knowledgeable about the intended locale. Pay attention to fonts, ideographic punctuation, vertical or horizontal conventions, spacing around Latin terms and the appearance of complex characters at small sizes. A technical inventory can reveal which fonts were embedded, but only the page image shows how they appeared.

Line breaks can be problematic in narrow columns. A long label may overflow or be clipped at a border. A caption may appear visually aligned but be too small to read. Rendering exposes these layout defects that text extraction alone can miss.

Keep the chosen font’s license and distribution requirements separate from visual suitability. A font may render well but not be authorized for a specific embedding or commercial use. Publication approval needs both technical and legal confidence.

Latin accents, combining marks and long translated words

Languages using the Latin script can still produce difficult layout bugs. French accents may collide with tightly spaced uppercase headings. Vietnamese has multiple tone and vowel marks that need clear vertical room. German compound nouns may overflow narrow controls. Turkish dotting distinctions and Romanian diacritics may expose font fallback problems.

Test the longest meaningful headings in each locale, not only typical sentences. Review line breaks, hyphenation, button labels in screenshots, running headers and table columns. Translators may provide the correct wording but the layout must still allow it to be seen. Shrinking every font to fit should not be the automatic solution; redesigning the space may better protect readability.

A high-resolution render can reveal whether marks are distinct, but reviewers must also check the page at normal reading size. A sentence that looks legible at 400 percent zoom may be unreadable in print or on a phone. Apply the document’s intended usage conditions.

If a heading no longer fits, explore source-level alternatives: more width, different text hierarchy, controlled wrapping or a reviewed shorter translation if appropriate. Do not silently change approved meaning to solve a visual constraint.

Mixed-script numbers, currencies and measurement units

Technical and public documents often mix local-language text with universal-looking numbers. That creates a false sense of safety. Decimal separators, thousands grouping, minus signs, currency marks and measurement units can differ by locale or context. An output image may reveal misalignment, clipping or a substituted symbol, but it cannot certify that the numeric meaning is correct.

Choose test cases with negative values, decimals, ranges, percentages, superscripts and units. Render them in the actual table or instruction where they appear. Inspect whether a minus sign is visible, whether a degree symbol has become a tiny circle and whether narrow cells obscure trailing digits. Even a subtle rendering defect can alter how a safety instruction is interpreted.

For Arabic and Hebrew documents, observe how digits and units align inside right-to-left paragraphs. For Japanese reports, check mixing of Latin abbreviations with full-width characters. For currencies, confirm that typographic placement matches the intended locale, but also ask a finance specialist to verify actual figures.

Maintain a separate numerical QA record. A design reviewer can confirm legibility; a domain specialist must confirm values and conventions. Good translation publishing connects those approvals without pretending that the renderer performs both jobs.

Page boxes: why the crop may hide correct content

A PDF may describe several page boxes for media, cropping, trimming and other production purposes. Mutool draw supports selecting a named page box with -b in documented builds. Rendering the default visible page may differ from rendering another box. This matters when content appears outside the intended trim area or disappears at the edge.

If a translated heading seems cut off, first check whether the authoring layout placed it too close to the page boundary. Then consider whether the viewer or renderer is using a crop that hides content. A page could contain text objects beyond the CropBox that are still visible to certain inspection tools, yet readers do not see them in the usual view.

Do not ‘fix’ clipping by choosing a different diagnostic page box and declaring success. The released PDF must display correctly in the intended viewing and printing context. The alternative box is useful for explaining why content vanished, not for excusing it.

Record the selected box in comparison tests. Two renders of the same PDF using different page boxes can look dramatically different even when no translation content changed. A consistent test setup prevents false alarms and missed defects.

Rotation, orientation and atypical page geometry

Some reports include landscape tables inside an otherwise portrait document. Others contain rotated charts or pages imported from different sources. The -R option can apply a rotation during rendering in supported MuPDF versions. That is useful for inspection but it should not be confused with repairing the PDF’s own page orientation.

A reviewer may rotate an output image to read a sideways label, while the published file still presents that page awkwardly in a normal viewer. Document the original orientation and the intended reader experience. If the file itself needs a rotation change, make that change in the appropriate source or PDF-processing workflow and revalidate it.

Page size changes also matter. A document assembled from several translations can contain inconsistent dimensions, leading to a distracting flip between A4, Letter and custom page sizes. Render an overview set or inspect page geometry separately to identify unexpected variations. The visual images can reveal changes in margins, borders and header placement.

For double-sided or print-bound work, remember that even and odd pages may use different margins. A screenshot from one page is not enough. Review the full spread, gutter spacing and trim expectations with the production team.

Color spaces and contrast

A localized chart may use colors to distinguish categories, warnings or regions. MuPDF provides color-space controls, including RGB and gray variants in documented versions. Rendering a grayscale version can be a useful diagnostic for situations in which color differences disappear or low contrast makes labels difficult to read. It is not a substitute for a complete accessible color-contrast evaluation.

Check text against its actual background and at intended size. A translator might make a label longer, pushing it onto a differently colored area. Small punctuation can disappear against a gradient. A contrast problem can therefore be introduced by text expansion even when the color palette itself is unchanged.

Screenshots should be viewed in more than one relevant environment when color accuracy is important. ICC workflows, monitor settings, print processes and image-format choices can influence appearance. A single PNG cannot prove final ink output will be perfect. For print jobs, the prepress team needs separate proofing.

Do not infer meaning from color alone. If an instruction depends on red and green marks, consider whether labels, symbols or other redundant cues are needed. Translating the label correctly does not repair a design that is ambiguous in grayscale or to readers with color-vision differences.

Anti-aliasing and why pixel differences can mislead

Anti-aliasing smooths edges when shapes are rendered to pixels. Different settings or versions can change edge pixels while leaving the text equally legible. Mutool draw documents anti-aliasing controls. For automated visual regression, inconsistent settings can create large differences that are unrelated to source text or layout.

Choose and record a standard rendering configuration. If the tool version changes, regenerate a baseline and review representative pages rather than silently comparing across unlike environments. Pixel-level thresholds should be tested with real examples of both harmless edge changes and serious missing-character defects.

A missing accent may affect only a small group of pixels, while a harmless gray antialiasing difference may affect the entire page. Raw difference counts are therefore not a substitute for human judgment. The best comparison system helps reviewers focus on likely problems, perhaps using regions and semantic expectations rather than one global percentage.

When a visual diff flags a difference, inspect the actual page images side by side. Ask what changed for the reader. Is the word different, or only its pixel edge? Is a warning missing, or has the image’s color profile shifted? Classifying the difference is the core skill.

Scenario: a French heading touches the line above

A brochure contains an uppercase French heading with several accents. At normal zoom the text seems crowded; at higher resolution, the marks collide with the preceding line. A naïve automated text comparison might pass because all characters are encoded correctly. Render the page at a consistent DPI, compare it with the approved design and identify the exact heading.

Check the source document’s line height, font metrics and style rules. A translation may have become longer and wrapped to an additional line while inheriting fixed-height spacing. Adjust the layout upstream rather than removing essential accents or inventing an inaccurate shorter phrase. Keep linguistic approval separate from typographic adjustment.

Render the corrected page again, including neighboring paragraphs and the page footer. More line space can push other content downward, so the original issue should not be considered solved until the whole page is checked. If this heading style appears elsewhere, sample other pages too.

Record a before-and-after crop with the surrounding context. The case becomes a useful regression test when the template or export engine changes later.

Scenario: Arabic punctuation looks reversed near a URL

An Arabic travel notice includes an English URL and parentheses. The rendered page places the closing punctuation in a confusing position. The visual comparison correctly raises a flag, but changing resolution or font antialiasing will not resolve a bidirectional layout issue.

First confirm the intended sentence with a fluent reviewer. Then examine paragraph direction, the segmentation of the URL and any explicit direction controls in the source. Preserve a copy of the approved Unicode text. If the PDF extraction has a different logical order, address that as a separate problem.

Use mutool draw to render the corrected export and inspect the entire mixed-script line, not only the punctuation. Verify that the URL is legible, unbroken or broken at acceptable points, and selectable when required. A page that merely looks tidier may still be difficult to copy into a browser.

Document the source-level correction so future editors do not accidentally reintroduce the problem when updating the URL.

Scenario: a Japanese label collides with a chart boundary

A Japanese market report has a chart with translated category labels. One long label touches the edge of a shaded region and becomes hard to distinguish. The characters themselves may be correct. The problem is the available geometry and its interaction with typography.

Render the page and inspect at normal size and higher resolution. Compare the chart label with the authoritative translation and the underlying data category. A design adjustment such as moving the label, widening the chart area or changing hierarchy may be better than unapproved abbreviation.

Check adjacent labels because changing one can affect overall alignment. If the chart was generated separately and embedded into a PDF, confirm that the exported chart itself uses the proper font resources. The main page’s typography may be correct while the embedded figure follows a different workflow.

A good sign-off involves the translator, chart owner and designer. The screenshot provides common evidence, but their approvals cover different dimensions.

Scenario: a Hindi manual shows detached combining marks

A Hindi maintenance guide includes several words with vowel signs and conjuncts. On a particular page, some marks seem separated from the base characters. The page image makes the fault visible, but the precise cause could involve font coverage, shaping, text representation or a renderer-specific behavior.

Compare the approved Unicode string, text extracted from the PDF and images rendered by two different viewers. If the strings match but the visible results differ, investigate shaping or rendering. If the extracted string differs, consider PDF mapping. Avoid replacing the correct Hindi word with visually similar characters merely to get one render to look right.

Test the corrected PDF at realistic print size. A high-resolution crop may hide the fact that small marks remain indistinct to users. Also check a bold heading and a narrow caption, because layout changes can expose new failures.

Preserve the failing phrase as a regression test. One real, meaningful example often teaches the team more than dozens of abstract font specifications.

Scenario: a technical number is clipped by a table cell

A multilingual laboratory report contains a negative value with units. A translated column header becomes wider and changes cell allocation, causing part of the number to be clipped. The extractor may still recover the entire number, so text-only QA would miss the presentation defect.

Render the relevant page and zoom into the table. Compare the visible amount with the approved source data. Ask the domain specialist to verify whether the missing character changes meaning. Then repair the source table layout by adjusting widths, wrapping or hierarchy rather than reducing every font indiscriminately.

After re-export, render the entire table and nearby footnotes. A correction to the header can move another value or obscure a unit. Check all rows, especially those with unusual lengths or negative signs.

This illustrates a fundamental limit of automation: a small, high-risk change may be more important than a large decorative difference. Visual checks need severity and context.

Scenario: a merged manual has inconsistent pages

A publisher combines translated chapters prepared by different contributors. The PDF opens, but one chapter uses a visibly different margin and some pages appear rotated. A full set of page images creates an overview that makes the inconsistencies easy to find.

Before changing the file, confirm that the differences are not intentional: appendices may use landscape layout or different paper sizes. Compare against the publication specification. If a section was exported with the wrong template, return to that contributor’s source rather than performing an unexplained patch to the combined PDF.

Check whether page numbering, bookmarks and references still align after any correction. The images show visible layout, but navigation and text-extraction tests are also needed. A combined document can look coherent while containing broken links or reading-order issues.

Maintain a clear relation between the approved chapter editions and the final merged document. The latter needs its own release sign-off because assembly can introduce problems not present in individual files.

Scenario: a scan and a live-text page look identical

Two pages of a manual look almost identical when rendered as PNG images. One contains live text; the other is a scan of printed text. Rendering alone cannot tell readers whether they will be able to search, select or copy the words. A good visual result therefore does not imply that a document is usable through assistive technology.

Test extraction separately. If a page is an image, consider whether an authorized OCR workflow and an accessible text alternative are required. Verify recognized text against the actual scan. OCR can misread numbers or similar-looking letters even when the screenshot appears clean.

If the source is archival, preserve the original visual evidence and keep any recognized layer or translated transcription clearly identified. Do not let a reconstructed page silently replace signed, stamped or historical material.

This case demonstrates why rendering, text extraction and document structure should be reviewed as independent dimensions. The fact that an image looks right is valuable but incomplete.

Building a reliable multilingual visual regression suite

Start with a carefully selected set of pages: long headings, tables, footnotes, mixed scripts, diagrams, legal clauses, symbols and varied page sizes. For each, record the language, content purpose, expected appearance and original approved text. Render the same pages consistently after exporter or template changes.

Your comparison process should distinguish intended changes from accidental ones. A translation revision may legitimately change line breaks, and two locales should not necessarily have pixel-identical pages. Instead of comparing every language to English as a fixed image, compare each localized revision to its own prior approved layout and review against its own requirements.

Automated image differences can help triage the workload. They should not automatically reject every antialiasing change or accept every small difference. Build a manual review step for high-severity areas such as numbers, warnings and navigation labels. Maintain issue categories, severity and clear closure evidence.

Periodically update the suite with real defects. Every newly discovered clipping problem, missing mark or reversed punctuation example can become a reusable test. The collection gains value over time when it reflects readers’ actual difficulties instead of only idealized sample text.

Accessibility and visual presentation are complementary

Visual QA matters to everyone who reads a page, including people using magnification or enlarged print. But an image cannot reveal document structure or tell a screen reader which heading comes next. Accessibility depends on tags, language attributes, reading order, alternative text, tables, links and practical assistive-technology behavior.

A report that renders perfectly may have a broken text layer. Another may have correct text extraction but lack proper structure. A third may be accessible to a reader using speech output while being too cramped for a reader with low vision. A responsible publication process considers all these different needs.

For multilingual material, language changes inside a page deserve special attention. A figure caption might contain English abbreviations inside a Thai report. Visible rendering cannot tell whether an assistive reader is instructed to switch pronunciation appropriately. Include that question in a separate structural review.

The goal is usable communication in more than one language, not merely a screenshot that looks polished. Provide an accessible alternative edition when that better serves the audience and fits the publication requirements.

A step-by-step release process

First, obtain the approved translation and a controlled source document. Confirm target languages, audience, technical terminology, values and locale conventions. Export the PDF using the intended fonts and settings, then record its revision. Do not start QA against a file that continues to change unpredictably.

Second, render representative or all pages with mutool draw, using a recorded version and settings. Inspect long text, mixed scripts, tables, charts, symbols and page boundaries. Pay particular attention to areas where translation expansion changes layout. Compare the outcome with source design and target-language expectations.

Third, verify extracted Unicode text and document structure separately. Investigate any difference between the rendered appearance and the text layer. Fix problems in the source whenever possible, re-export and rerender the failing page plus adjacent and representative pages.

Finally, secure approval from language, design, domain and accessibility reviewers according to the publication’s risk. Store concise evidence, including exact commands and screenshots, and release the intended final PDF. A visually correct intermediate draft is not sufficient if the delivered file differs.

Frequently asked questions

### Does mutool draw translate text? No. It renders or converts document content to supported output formats. It does not judge the meaning of sentences or produce an approved target-language translation. Use it to inspect what the localized PDF looks like, then rely on competent language reviewers for accuracy.

### What resolution should I use? Choose one appropriate to your test and keep it consistent. Modest DPI helps with page overviews; higher DPI makes small marks easier to inspect. Always judge real-world readability at intended output size as well. A higher-resolution image is not proof that the source PDF is correct.

### Why does a pixel diff show thousands of changes? Renderer versions, fonts, antialiasing, colors and page geometry may change pixel values without changing meaning. Compare under the same settings, inspect the actual page images and classify differences by their effect on readers. Small missing punctuation can matter more than large cosmetic changes.

### Can I use a screenshot to verify Unicode correctness? No. Visually identical glyphs can represent different code points, and an image may not reveal broken copy-and-paste mappings. Extract the text and compare it to approved Unicode strings. Keep screenshot and text-extraction evidence together.

### Can mutool draw fix a missing Arabic joining form? No. It renders the document it receives. A missing or incorrect joining form may require changes to source text handling, font selection, shaping or PDF export. Use rendered images to describe and verify the problem, not as a substitute for fixing its cause.

### Why do pages have different margins or sizes? The source document may use different templates, page boxes or orientations, especially after merging files. Some differences are intentional; others are export defects. Compare the rendered pages against the publication specification and repair unapproved inconsistencies.

### Does an image of a page prove that it is accessible? No. Images cannot certify heading tags, reading order, language identification, table structure or usable alternative text. Conduct a separate PDF accessibility audit and user-centered testing. A document can look excellent while remaining difficult to navigate through assistive technology.

### Is rendering every page always necessary? Risk determines coverage. A short or high-stakes document may justify full inspection. A long manual may begin with automated overview renders and targeted review, followed by broader release checks. Record what was sampled and why rather than claiming untested pages passed.

### Should I use image output as the final translated document? Usually not as a replacement for a properly constructed text-bearing PDF. Rasterizing pages can remove text selectability and structural information. Image output is excellent for visual diagnostics, previews and defined workflows, but the accessible final deliverable should be chosen for readers’ needs.

### How do I investigate differences between viewers? Capture the same PDF in each environment, record versions, fonts and settings, then compare the exact symptom. If the issue appears only in one renderer, investigate interoperability without assuming the PDF is entirely correct or entirely defective. Validate the supported reader environments before release.