Translate Like a Pro | 11990 — pdfcpu CLI: PDF Validation, Optimization, Extraction, Bookmarks and Multilingual Release QA

pdfcpu is a command-line PDF toolkit that can validate, inspect, optimize and extract resources from a document before a multilingual translation release. It can help a localization team notice unexpected PDF structure, embedded images, font resources, bookmarks and attachments, but it cannot decide whether a Spanish safety warning is correct or whether an Arabic sentence reads naturally. A sound pdfcpu CLI workflow combines document-level checks with linguistic, visual and accessibility review instead of confusing a valid PDF with a validated translation.

This practical pdfcpu tutorial is for people searching for PDF validation commands, PDF optimization without losing quality, metadata inspection, bookmark checking, embedded-font extraction or safe multilingual PDF delivery. It explains what each operation can establish, what can change when a PDF is rewritten, and how to compare the output against the approved source. Because pdfcpu is actively developed, verify flags against the installed version with pdfcpu help and the current project documentation, especially when changing configuration, signatures or encryption.

Validate and inspect a copy of each locale-specific PDF before attempting optimization or restructuring.
Keep untouched source files, release manifests, file hashes and explicit output paths for every operation.
Distinguish PDF technical validity from linguistic quality, text extraction, visual typography and accessibility compliance.
Inspect images, fonts, bookmarks, document metadata and security restrictions without assuming their presence proves correctness.
After a rewrite, compare pages, text, links, signatures and document properties before releasing the result.

Where pdfcpu belongs in a translation workflow

A translation may begin as an editable document, a structured XML manual or a layout file. After that content is approved, a publication tool creates a PDF. pdfcpu belongs mostly at the delivery and inspection stage: it can look inside the PDF container, validate its structure, optimize redundant resources, and support controlled extraction or organization. It does not replace the authoring software or a qualified translator. That division of responsibility makes troubleshooting much easier when several teams contribute to the same file.

For example, a translated warranty guide may look correct when opened in one viewer but contain a broken bookmark tree or unexpectedly large embedded images. pdfcpu can help diagnose parts of that situation. A different tool may be needed for searchable text, logical reading order or accessibility auditing, and a native speaker must still approve the warranty conditions. Think of the PDF as a product made of several layers: meaning, page appearance, navigation, metadata, security, and underlying objects. Inspect them separately.

Start with provenance and original file custody

Before using a tool that can write a new document, preserve the approved PDF and its source files. Record the language tag used by the publishing team, document revision, publication date, producer, source filename, output filename, checksum and release owner. Never use the only copy of a signed, legally controlled or regulated PDF as the experiment input. A valid optimize command may create a different byte sequence, and the consequences matter when the original is evidence of approval.

Create clearly named folders such as originals, diagnostics, candidates and approved. A candidate should not inherit approval simply because its filename resembles the old edition. When multiple languages share a build server, keep their manifests and output directories apart. An editor must be able to answer: which translated source produced this exact file, which tooling modified it afterward, and which reviewers approved the file now being offered to readers? If those answers are unavailable, the technical work is not yet ready for release.

Validate without overclaiming

The pdfcpu validate command checks whether PDF structure conforms to the tool’s supported validation rules. It can detect or report issues in internal object relationships, syntax or other aspects of the file. That is valuable when receiving a supplier’s output or checking a newly built manual. However, a pass does not prove that the PDF uses the correct fonts, carries an accessible reading order, preserves the translation or conforms to every PDF/A or PDF/UA requirement.

Use validation as one gate in a larger set. If a file fails, capture the diagnostic output and decide whether the defect originates in the PDF producer, a later processing step or a damaged transfer. If it passes, continue with actual page rendering, protected-value comparisons, navigation testing and linguistic review. A team that stops at validate may ship an impeccably formed PDF with an incorrect dosage, wrong model code or missing warning. PDF compliance and content correctness are separate questions.

Inspect first and modify later

The pdfcpu info command gives a starting point for document characteristics. It is useful to compare candidate and approved editions, notice unexpected page-count changes, or investigate whether the file has metadata or other features that require closer inspection. Reading information is generally safer than altering a production document, but even diagnostic operations should run in an environment suitable for confidential customer materials.

Create a small baseline report before optimization. It might contain page count, PDF version, file size, encrypted status, metadata observations, validation result and expected locale. These are not universal quality thresholds. A German manual can legitimately gain pages relative to English, and a Japanese edition may use different fonts. The goal is to explain differences and distinguish an expected result from a surprise. Archive the report beside the source revision so the next release has an objective comparison point.

Optimization is not permission to change the publication

pdfcpu optimize can reduce redundant resources and reorganize PDF internals. It may help large document collections distribute more efficiently. But optimizing a multilingual file is not the same as approving the result. Embedded fonts, images, page resources, annotations and metadata are integral to readability and may be affected by transformations in ways that warrant testing. Signatures require particular care: rewriting a signed PDF can invalidate its signed byte range.

Keep optimization conditional. First establish a measured problem, such as unusually large download size, and identify a target that does not sacrifice page meaning or display. Write to a separate candidate filename. Compare both files with identical page rendering settings, text extraction and navigation checks. Do not automatically remove encryption or signatures to make an optimizer succeed. A signed official certificate is not an ordinary marketing brochure, and the correct action may be to leave it unchanged.

Choose configuration deliberately

pdfcpu maintains configuration options that can influence resource handling and operational behavior. Current documentation distinguishes ordinary file-backed configuration from a stateless mode. A container job that invokes pdfcpu with a different configuration root from a developer’s laptop may behave differently, especially where fonts or trusted certificates are involved. Record the chosen mode as part of the build environment rather than relying on hidden defaults.

Use the project’s documented config inspection and validation commands when diagnosing configuration. For a controlled deployment, mount or prepare the intended configuration root; do not point casually to an arbitrary user’s home directory. Stateless operation can be valuable for reproducibility, but it also lacks some external resources. If a PDF-processing step depends on installed fonts or certificate material, test it explicitly. Otherwise the same script may appear reliable in development and fail in production for reasons unrelated to translation.

Extract images and fonts for investigation

The extract command can write selected PDF resources to a working directory. An image inventory can reveal that a supposedly text-only manual contains high-resolution screenshots, and a font inventory can help explain why a translated edition grew dramatically in size. The command’s extraction modes and page-selection features should be checked against the installed release; a useful documented pattern is pdfcpu extract -mode image input.pdf outdir for image resources.

Extracting an image is not the same as recreating the image’s visible crop, transparency, or appearance on a rendered page. Nor does the presence of a font resource prove that every character has a correct text mapping. Use extracted resources to investigate discrepancies and preserve the original PDF. Do not use the result as an unauthorized way to republish copyrighted assets or to circumvent document restrictions. Technical inspection should serve an approved workflow.

Metadata is part of reader trust

Metadata can describe a document’s title, producer, author or other attributes. A multilingual edition sometimes inherits the source-language title even after every visible heading has been translated. Other times the metadata may expose an internal draft filename or personal name that should never have shipped. Checking metadata is therefore both a usability and privacy practice. A reader using a file search interface may see metadata before opening the first page.

Define the intended metadata fields in the release specification. Check that titles and language-related properties are meaningful to the audience, and avoid inserting private translation-vendor details or unnecessary personal identifiers. Be careful about claiming an automatic PDF language value exists merely because the filename contains a locale code. If the publishing process needs a document-level language property for accessibility, verify that specific property using suitable tools and the actual PDF output.

Bookmarks and the outline tree

Long PDFs become much more usable when their bookmark hierarchy follows the real content structure. A language edition may have an accurate table of contents but a bookmark labelled in the source language. pdfcpu offers bookmark inspection and import or export workflows. Those operations can help manage an outline, but importing bookmarks changes the document and therefore needs a controlled source file and validation afterward.

Review bookmark depth, wording, target page and destination semantics. A bookmark called ‘Troubleshooting’ must not jump into an unrelated appendix because page numbers shifted. When importing a JSON bookmark representation, start from an export of the same document where possible and test on a copy. A correctly formatted JSON file is not enough: it must point to the intended sections of the exact edition. Document restructuring and translation should not silently get mixed together.

Page count changes can be normal or alarming

Languages expand differently, and typography, script choice and word-break rules affect pagination. A translated edition may need additional pages while maintaining complete content. But an abrupt page-count difference might also reveal a missing chapter, oversized image, incorrect font substitution, or broken table. pdfcpu information and page-level workflows can help detect anomalies, but the explanation must come from comparing source and target content.

Do not use a rule such as ‘all languages must have the same number of pages’ as a release criterion. Instead select representative chapters and expected structural landmarks: first safety warning, calibration table, warranty section and final glossary. Confirm each is present, searchable where intended, and navigable. Review the last pages carefully, because overflow and missing-footnote defects often appear there after text expansion. A numeric page-count comparison is only the start of diagnosis.

Encryption, permissions and signatures

PDF encryption and permissions can influence what readers and automated tools may do. Some pdfcpu commands can work with authorized credentials or document settings. That does not mean the translation team should remove access controls casually. An encrypted customer contract, a signed medical record and a publicly distributed brochure carry different obligations. Preserve the legal and security decisions made by the document owner.

If validation or extraction reports a permissions problem, find out whether the task is authorized and which credentials the owner provides through an approved secure channel. Do not put passwords into shared shell history or public logs. For signed documents, determine whether post-processing would invalidate a signature and whether a fresh approved signing process is required. Security controls are not cosmetic file attributes that can be stripped solely for convenience.

Text extraction cannot be inferred from appearance

PDF text can be stored using font-specific encodings and mappings that affect copy, search and assistive access. A page can look perfect on screen yet yield nonsense when someone copies a paragraph. pdfcpu can reveal structural information and resources, but specialized extractors such as Poppler pdftotext can test text behavior directly. For high-value documents, compare extracted text against approved source strings and native-language expectations.

Use deliberate test phrases containing accents, combining marks, punctuation, Latin and non-Latin digits, and language-specific characters. Copy text from several pages in the actual reader. Test whether a product model number remains contiguous. An extracted text file is not a replacement for visual layout review; it can miss reading-order problems or conceal visual clipping. Maintain separate results for visible page fidelity and text semantic fidelity.

Fonts, shaping and fallbacks

A font list can show which resources a PDF declares, but language support is broader than listing a font name. Complex scripts can require shaping features and correct glyph ordering; some font subsets omit glyphs that a later revision needs. A PDF may also depend on fallback fonts provided by a viewer. A release team should know what fonts were used, why they were selected, and whether embedding is licensed.

Check visual rendering on machines unlike the publisher’s workstation. Include a long translated heading, numbers inside right-to-left text, punctuation and mixed-language acronyms. Extract a sample of text as well as rendering pages. If defects originate before PDF generation, fix the authoring and renderer configuration rather than attempting to patch a finished PDF with a structural utility. Such a repair may hide the underlying issue and make the next release fail again.

Embedded files and supplementary materials

Some PDFs carry embedded source documents, spreadsheets or other attachments. These can be legitimate parts of an archival package, but they can also become accidental disclosures. A translated report may contain an English appendix spreadsheet that has not been reviewed, or an obsolete internal memo included during production. Treat attachments as separate release artifacts with their own content, permissions and malware-scanning requirements.

Use the appropriate extraction or inspection tools and test whether the delivered PDF contains any additional files. Do not assume an attachment is authorized merely because it was present in the previous language edition. Some attachments may need localized equivalents; others must remain in a single official form and be described accurately. A publication checklist should state the expected attachment list explicitly and flag unexpected extras before release.

Links, destinations and action safety

A PDF may contain clickable links to product support pages, related chapters, websites, email addresses or action objects. Link behavior can differ from the visible text. A sentence can tell the reader to visit the French help site but open an English page or, worse, an obsolete endpoint. Structural tooling can contribute to inspection, but human reviewers should click representative links in a safe viewer and confirm destinations.

Set a policy for what links may change by locale. Stable safety bulletin IDs should not be rewritten for style, while reader-facing support links may need localized routing. Review external domains before publishing, especially when an automated translation system created text around the link. PDFs can contain active content and unusual actions, so security review is necessary for untrusted input. A correct link label is not sufficient evidence of a safe or accurate destination.

Accessibility is a separate acceptance test

People often assume that an accessible PDF is one whose text can be selected. Accessibility involves more: reading order, semantic tags, headings, tables, alternate descriptions, document language, keyboard navigation and usability with assistive technology. pdfcpu validation is not a substitute for an appropriate PDF/UA assessment or human accessibility review. Nor does a small file size indicate good accessibility.

Make accessibility criteria explicit at the start of the publication project. Check output with suitable specialist validation and real reader workflows when required. If optimization changes the PDF, rerun relevant tests. A file may remain visually indistinguishable after rewriting while metadata or structural features change. The safest assumption is that modifications require renewed evidence for every feature covered by a delivery contract.

Use compare-before-release discipline

The most important question after running a PDF command is not ‘Did it finish?’ but ‘What changed and was that change intended?’ Compare original and candidate file size, page count, rendered pages, extracted strings, bookmark targets, links and security characteristics. Prefer an automated test report that names the exact input and output hashes. Different byte sequences are expected after optimization, so a checksum mismatch alone cannot explain quality.

For a large collection, select risk-based samples as well as general automated checks. Inspect files with complex scripts, long tables, handwritten seals, forms and mixed-language footers. Check the first and last page of each manual and all high-risk warnings. Retain the ability to fall back to the approved original if post-processing introduces a defect. A rollback plan is part of quality assurance, not evidence that the publishing team expects to fail.

Understand exit codes, logs and human decisions

A tool’s successful exit code says its requested operation completed to its own satisfaction. It does not certify every business requirement. Preserve the command, exit code, version, configuration and relevant output without flooding logs with sensitive text. Review reported warnings individually; some are informational, while others reveal a genuinely unshippable file. Do not automatically mark every warning as harmless simply because the document opens in one viewer.

Use a named decision owner for each failure category. Document engineers can correct structural defects; designers can address visual regressions; translators and subject specialists can approve wording and technical meaning; compliance owners decide on standards and signatures. The release record should show which issue was fixed, what test confirmed the correction, and whether the candidate was rebuilt from controlled inputs. This is more reliable than a final checklist consisting only of green command statuses.

Design a repeatable release pipeline

Begin with the approved locale PDF and an immutable source manifest. Run pdfcpu validation and information inspection. If optimization is justified, create a candidate copy, inspect its internals as required and compare expected metrics. Then run independent text, visual, link, accessibility and linguistic tests. Keep a quarantine area for failures. Promote a file to approved only after the responsible reviewers sign off and the manifest records the release checksum.

A small organization does not need an elaborate server farm to follow this practice. A directory structure, a script that fails visibly, a spreadsheet of approval decisions and a controlled archive are enough to begin. Scale the automation only after a human can reproduce one successful run end to end. The enduring goal is not more commands; it is a PDF that a reader can trust in the target language and a release that an editor can explain.

Rights, ethics and the limits of processing

Documentation teams handle many kinds of PDFs: public brochures, customer-provided manuscripts, records subject to privacy law, and copyrighted third-party work. The presence of an extraction or encryption option does not confer a right to use it. Work only on material for which processing is permitted. Follow the document owner’s retention policies and secure handling rules. If a file’s permissions conflict with a proposed workflow, seek authorized access or a source document instead.

The ethical boundary is also a quality boundary. Rebuilding from authorized source files generally provides better typography, accurate strings and traceable approval than trying to reconstruct editable content from an opaque final PDF. pdfcpu is most useful as a controlled inspector and processor in that larger workflow. It should not be sold to readers as a magic translator or as a way around approval, copyright or security obligations.

Core commands for a controlled inspection

These examples reflect the project’s published command families. Run pdfcpu help and command-specific help against your installed binary before using them in a release script. Paths below are illustrative. In particular, preserve an untouched original and do not optimize or otherwise rewrite a signed or regulated PDF without approval.

pdfcpu validate approved-fr.pdf
pdfcpu info approved-fr.pdf
pdfcpu optimize approved-fr.pdf candidate-fr.pdf
pdfcpu extract -mode image approved-fr.pdf work/fr-images
pdfcpu extract -mode font approved-fr.pdf work/fr-fonts
pdfcpu config inspect
# For a stateless validation run when appropriate:
pdfcpu --conf disable validate approved-fr.pdf

Practical situations: what to check, why it matters and how to decide

A file is 90 MB rather than 6 MB

First identify whether the extra size comes from legitimate high-resolution translated screenshots, repeated image objects, redundant font subsets or unnecessary embedded materials. Check dimensions and page-level appearance before compressing. A drastic size reduction is not a victory if diagrams lose fine labels or accented characters turn into squares. Use a candidate copy and compare screenshots at practical zoom levels, especially for technical drawings.

A signed certificate fails after optimization

A cryptographic signature can protect the byte representation of the original file. A post-processing tool may change those bytes even if the human-visible page is unchanged. Do not keep optimizing until a viewer stops warning. Preserve the signed original, ask the document owner whether a new signing process is authorized, and distinguish delivery convenience from authenticity obligations.

The French filename is correct but its metadata is English

Inspect the approved metadata specification and the actual PDF fields. A title shown in a download list can confuse readers even when the page’s title is translated. Correct the metadata in the source publishing pipeline where possible, rebuild, and check other locale editions for accidental copying. Do not assume that a file named manual-fr.pdf has a French document language property.

A bookmark opens the wrong chapter

The document acquired new pages after translation but bookmarks were copied from the source file without updating destinations. Inspect the outline tree and click a sample in a real reader. If bookmark JSON is being imported, regenerate it against the exact target document. A correct hierarchy on paper does not help readers when destinations remain tied to obsolete page locations.

An Arabic PDF appears perfect in one viewer

A second viewer may use different fallback resources or text behavior. Test the document on more than one supported platform, then copy a sentence containing Arabic text, Latin model codes and punctuation. Ask a fluent reviewer to verify logical and visual order. The presence of an embedded font alone cannot certify meaningful shaping and text extraction.

An embedded Excel file has not been translated

A multilingual PDF may carry an attachment that was never in the translation package. Inventory attachments separately and decide whether they are required, accessible, approved and safe to share. If an official spreadsheet must remain untranslated, explain its status accurately to the reader. Do not ship it silently under the assumption that translating the PDF pages was sufficient.

Validation passes but a warranty amount is wrong

A PDF validator cannot tell whether an amount, duration, serial number or legal condition was mistranslated. Compare protected fields against controlled source values and require specialist review. Separate a structurally valid file from a semantically correct publication in the final sign-off. This prevents a green automation result from overruling the evidence of a human content error.

A scan has no selectable text

The PDF may be made of page images. pdfcpu can help inspect resources, but producing a trustworthy text layer is a different task involving OCR, language data and verification. Use an approved OCR workflow if searchable text is required, then check recognition of names, amounts, mixed scripts and reading order. Do not claim that extracting images is equivalent to translating the document.

A footer contains personal data

Metadata and page content can both reveal names, paths or other information not intended for readers. Check the visible footer, PDF metadata and embedded files. Removing a line from a displayed page might not remove hidden remnants or attachments, so use an approved redaction process for confidential content. Ordinary optimization is not a secure redaction operation.

A PDF opens locally but fails on the customer portal

The file may be damaged during upload, rejected by a gateway, blocked by security policy or served with an incorrect content type. Compare hashes from the approved release and downloaded copy. Check page count and validation on the actual retrieved artifact. Avoid responding by editing the source content until the transmission or platform problem has been ruled out.

Fonts occupy most of the file

A multilingual manual may legitimately embed several font subsets to support its scripts. Investigate duplicates and license constraints before optimizing. Compare rendering, search and text extraction. Aggressive deletion of font resources can create dependence on a viewer’s installed fonts, turning a self-contained release into a document that displays unpredictably.

A PDF has an unexpected form field

An annotation or form element might be left over from an interactive source template. Determine whether it was intended for the reader and whether it behaves correctly in the target language. Check tab order and label comprehension. Do not remove interactive fields automatically, because a legitimate document may require them for consent or data entry.

The legal team approved a specific file hash

If the legally approved artifact is identified by its checksum, even a harmless optimization creates a different artifact requiring policy review. Keep the original, record the proposed change and seek explicit authorization for a replacement. The release team should not treat a technical pass as permission to override document governance or signature requirements.

A machine-generated PDF contains outbound links

Review link text and actual destinations, including locale-specific support pages. A visible translated phrase can mask an obsolete English-language URL. A document might also contain non-web actions. Test links safely and record exceptions in the release manifest. Avoid giving reviewers only screenshots, because those cannot demonstrate real click behavior.

A Japanese appendix is missing from the candidate

A surprising page-count reduction may be caused by a missing source module, a conditional export or a malformed input. Compare the source and candidate chapter inventory before attributing the difference to optimization. Check the first and last sections and the table of contents. Do not use automatic file-size thresholds as a substitute for completeness verification.

The tool uses different fonts in a container

Investigate configuration mode and installed resources. A stateless process may intentionally omit external font resources, while a developer workstation uses user-managed files. Reproduce with the same configuration and dependencies, and pin those details in the environment manifest. Treat cross-machine rendering differences as a release defect until explained.

The PDF includes a large unapproved image

An embedded image may be an outdated screenshot, private diagram or placeholder. Extraction can identify what resource exists, but the relevant decision belongs to the content owner. Verify image license and revision, replace in the authoring source, rebuild, and run document comparison rather than attempting to patch a final PDF silently.

Readers report incorrect copy-and-paste text

Do not rely on the visible pixels alone. Run an independent extractor, compare suspect strings with approved copy, inspect encoding and font mappings, and reproduce in readers used by the audience. For some files, rebuilding from an appropriate authoring source is preferable to structural edits. The correction needs to address both human display and machine-readable text.

A PDF/A deliverable fails compliance review

pdfcpu’s structural validation is useful but not a substitute for the precise archival conformance test requested. Use a designated PDF/A validator such as veraPDF for the required profile, and examine fonts, metadata, output intents and other applicable rules. Do not equate ‘PDF opened without error’ with archival certification or accessible PDF compliance.

An optimization step silently overwrites the source

The command may allow output to default to input for some workflows. Treat destructive overwrites as a preventable process defect. Always inspect the syntax, use an explicit output path, keep read-only originals and compare checksums before promotion. An automated pipeline should refuse to place a candidate directly in the release folder until validation and approval are complete.

Frequently asked questions

Is pdfcpu an automatic PDF translation tool?

No. It processes PDF structures and supports inspection, optimization and extraction. It does not understand whether a warning, contract clause or medical instruction has been faithfully translated. Keep a human-approved translation source and a language-specific release checklist.

What does pdfcpu validate actually prove?

It can establish whether the PDF passes the structural checks supported by the installed pdfcpu release. It does not certify PDF/A, PDF/UA, translation accuracy or appearance in every viewer. Run separate standards validators and actual text and visual checks according to the required delivery contract.

Should every delivered PDF be optimized?

No. Optimization should solve a measured problem and be reviewed as a file rewrite. A signed document, archival record or legally controlled artifact may need to remain bit-for-bit identical to the approved original. When an optimization is appropriate, test a new candidate rather than overwriting the source.

Can pdfcpu fix missing accented characters?

Not reliably by itself. Missing characters often originate in font selection, text encoding, renderer behavior or upstream layout. Inspect the PDF and its fonts, then repair the underlying authoring and publishing system. Confirm both rendered characters and extractable text in the rebuilt edition.

Why compare PDFs if both commands returned success?

Because tools report completion of their own operations, not approval of every reader-facing requirement. Page images, text mappings, bookmarks, annotations or signatures can differ after processing. A compare-before-release protocol explains what changed and preserves the source of truth.

Does a small PDF guarantee fast, accessible reading?

No. File size affects download convenience, not translation fidelity, reading order or assistive technology support. A highly compressed image-only scan can be difficult to search and inaccessible. Optimize toward stated reader needs rather than a simplistic byte-count target.

How should we handle encrypted customer documents?

Process only when authorized, use approved credentials and secure handling, and preserve relevant permissions. Avoid putting passwords in shell histories or logs. If a signed or encrypted document cannot be modified within the owner’s policy, seek an authorized editable source or keep the original unchanged.

What is a sensible first pdfcpu workflow?

Take an approved sample PDF, preserve a copy, run validate and info, record an input hash, test an explicit candidate optimization only when justified, and compare output. Add independent extraction, visual and linguistic checks. Reproduce this small sequence before attempting a multilingual batch.

Where should final corrections be made?

Whenever practical, in the controlled source document and publication configuration. Rebuilding ensures that other editions and future revisions inherit the correction. Editing a final PDF directly can be justified in narrow cases but needs documented approval and full regression testing.

Documentation, complementary tools and further reading

Confirm command syntax in the project’s installed-version help and its current documentation. The related guides below cover independent text extraction, PDF standard validation and font inspection. They complement pdfcpu rather than establishing that one tool can validate every dimension of a multilingual publication.