Validate PDFs Against the Arlington PDF Model with JPedal

A PDF that renders correctly can still be structurally wrong. The Arlington PDF Model is the PDF Association’s machine-readable definition of the PDF DOM, derived from ISO 32000-2, and JPedal now includes a parser and validator built against it. It runs from the command line for batch checking or from Java when you want the results inside your own application.

How It Works

The validator takes the Arlington model in TSV format and checks a file’s object tree against it.

What It Catches

Because the checks come from the model’s own predicates, coverage follows the specification rather than tracking which bugs happened to be reported. Findings include:

• Direct objects where the model requires an indirect reference
• Keys not defined by the model for that object, where no wildcard entry exists
• SpecialCase constraint failures, such as a /Widths array whose length does not match the /FirstChar and /LastChar range
• Type mismatches, such as an integer where the model expects a boolean
• Unprintable ASCII inside string values
• Values outside the permitted set for a key

What Comes Next

We are extending the validator to cover PDF/A. The goal is both directions of the problem: reporting where a file fails the PDF/A specification, and converting a non-conforming file so that it passes. If you have archiving workflows and opinions about what a PDF/A validator should tell you, we would like to hear them while the work is still in progress.

The JPedal Validator requires Java 17 or later and has no third-party dependencies. Full documentation, including command-line syntax and the Java methods, is on the JPedal documentation site.