This guide explains how to prepare documents, validate output, and troubleshoot fidelity issues when converting files to PDF/A with Nutrient Java SDK.

Use this guide when PDF/A conversion succeeds technically but a validation report, visual comparison, or large-scale proof-of-concept batch shows issues that need investigation.

PDF/A output quality depends on both the conversion engine and the source documents. Legacy PDFs, scanned/OCR documents, signed documents, and documents with missing fonts often need separate testing and triage.

What PDF/A conversion enforces

PDF/A is designed for long-term preservation. A compliant output file must be self-contained and avoid features that depend on external resources or interactive runtime behavior.

During export, the SDK applies PDF/A-oriented conversion behavior such as:

• Embedding fonts when they are available to the conversion process.
• Converting color information to compliant color spaces.
• Adding archival metadata.
• Embedding or resolving external resources where possible.
• Adjusting document structure for the selected conformance level.

These steps help create a compliant archival file, but they can’t always reconstruct information that wasn’t present in the input or available in the runtime environment.

Prepare source documents

Before running a large batch, inspect a representative subset of the source corpus.

Check for:

• Missing embedded fonts — A common cause of layout changes and font substitution.
• Encrypted or password-protected PDFs — Remove protection before conversion unless your workflow explicitly opens the file with credentials.
• External resources — Documents that reference external files, URLs, profiles, or fonts may not be fully reproducible later.
• Digital signatures — Converting a signed PDF changes the file and can invalidate the original signature appearance or signature state. Test signed PDFs separately.
• Scanned/OCR PDFs — These often contain an image layer plus a hidden text layer. Treat them as a separate class of input.
• Legacy or malformed PDFs — Older producer applications sometimes create files that render in common viewers but don’t follow the PDF specification strictly.

Avoid font substitution and fidelity issues

Font substitution happens when the source PDF references a font that isn’t embedded and the same font isn’t available to the SDK process. Substitution can change glyph shapes, spacing, line breaks, and table layout.

To reduce substitution:

1. Inspect the source PDF fonts.
   • In Adobe Acrobat, open File > Properties > Fonts and look for fonts that aren’t marked as embedded or embedded subset.
   • In automated workflows, use your preferred PDF inspection tool to report non-embedded fonts before conversion.
2. Install required fonts on the conversion machine or container.
3. Re-export source documents with fonts embedded when you control the source format.
4. Re-run conversion and compare the output against the original.

Install fonts in on-premises environments

The SDK can only use fonts visible to the process running the conversion. For containerized or server deployments, install the same font packages in every worker image.

Typical locations and commands:

• Linux — Install fonts through the system package manager or copy licensed fonts to /usr/local/share/fonts or ~/.local/share/fonts, then run fc-cache -f -v.
• Docker on Linux — Add font packages and custom fonts to the Docker image, not only to the host machine. Rebuild the image after changing fonts.
• Windows — Install fonts into the system Fonts folder for the account running the service.
• macOS — Install fonts system-wide or for the service user with Font Book or the relevant font directories.

Make sure your font licenses permit server-side installation and batch conversion.

Validate after conversion

Use a PDF/A validator such as VeraPDF after conversion, especially before processing a large batch.

A practical validation workflow is:

1. Convert a small representative batch.
2. Validate each output file with VeraPDF using the intended PDF/A profile.
3. Save the validation report with the input and output files.
4. Group failures by rule ID or error message.
5. Investigate repeated failures before scaling to the full corpus.

Don’t rely only on a pass/fail count. A small number of repeated rule violations can point to a specific document pattern, missing runtime dependency, or SDK version issue.

Build a representative proof-of-concept corpus

A useful POC corpus should include both ordinary production files and known problem files. Avoid judging production readiness from only the worst historical edge cases, and avoid testing only clean documents.

Include separate groups for:

• Native PDFs created by current systems.
• PDFs created by legacy systems.
• Scanned PDFs.
• OCR-processed PDFs.
• Signed PDFs.
• Documents with uncommon fonts or corporate fonts.
• Large documents and documents with many images.

Run and report results by group. This makes it easier to identify whether a problem is general or limited to a specific document class.

Troubleshoot common issues

The following sections describe common issues and how to investigate them. If you need to contact support(opens in a new tab), include the information described in the What to send support section.

The output fails PDF/A validation

Check:

• The selected PDF/A conformance level.
• Whether the source file is encrypted or malformed.
• Whether required fonts, color profiles, or resources are available.
• Whether failures cluster around a specific source system or document type.
• Whether you’re using the latest SDK version.

Keep the VeraPDF report. The failed rule IDs are important for support and engineering analysis.

The output looks different from the input

Most visual differences are caused by missing fonts, source-document ambiguity, or rasterization differences.

Check:

• Whether all source fonts are embedded.
• Whether required fonts are installed in the conversion environment.
• Whether the issue appears only in OCR/scanned files or legacy files.
• Whether the same file renders differently across PDF viewers before conversion.

OCR/scanned files behave differently

OCR PDFs often contain both page images and positioned text. Separate these from native PDFs during testing. They may have different failure patterns, file sizes, and fidelity expectations.

Throughput is lower than expected

For large batches, measure the full pipeline rather than only the conversion call.

Check:

• Disk and network I/O.
• CPU availability and worker parallelism.
• Container resource limits.
• Input document size and complexity.
• Whether validation, OCR, or pre/post-processing is the bottleneck.

Benchmark with your own corpus and deployment topology. Avoid assuming that results from another environment will match yours.

What to send support

When a specific file fails or renders unexpectedly, provide:

• The original input file.
• The converted output file.
• The VeraPDF report, if validation failed.
• SDK name and version.
• Operating system, container image, and CPU architecture.
• The conversion code or settings used.
• A list of installed fonts, especially in containers.
• Screenshots showing expected vs. actual rendering when the issue is visual.
• Whether the file is signed, encrypted, OCR-processed, or produced by a legacy system.

PDF/UA note

PDF/UA is an accessibility standard, while PDF/A is an archival standard. Some workflows require both, but they should be planned and validated separately. For accessibility-specific tagging and screen-reader requirements, use the PDF/UA conversion guidance rather than treating PDF/UA as a PDF/A troubleshooting topic.

Related guides

• Convert PDF to PDF/A with Java SDK
• Handle Java SDK errors