The Arlington PDF Model
The PDF specification is about a thousand pages of English. The Arlington PDF Model is the same object rules expressed as machine-readable tables: for every dictionary type, which keys exist, which are required, what types their values may take, which PDF version introduced them, and what constraints link them together.
Why that is worth having
Without it, every implementation re-reads the specification and encodes its own interpretation of each dictionary, by hand, with its own gaps. With it, the rules are enumerable: you can ask "what does ISO 32000 require of a Font dictionary" and get an answer a program can act on, covering keys nobody thought to test.
It also makes coverage measurable. A hand-written checker has an unknown number of blind spots. One derived from a model has exactly the blind spots the model has, which is a much better thing to have to reason about.
The checks gopdfrab derives from it
MissingRequiredKey: a dictionary omits a key the model marks as required for its type.WrongValueType: a key is present but holds a type the model does not allow there.DisallowedValue: the type is right but the value is outside the permitted set.IndirectRequired: a value the model requires to be an indirect reference was written directly.KeyIntroducedAfterPDF14: a key that postdates the document's declared PDF version. This is the one that matters most for PDF/A-1, which is based on PDF 1.4.ConstraintViolated: a relationship between keys the model expresses as a constraint does not hold.
Two different questions
Object-model conformance and PDF/A conformance are independent:
- A file using transparency is valid PDF and not valid PDF/A-1.
- A file with a Page dictionary missing a required key can still carry a correct-looking PDF/A identifier in its metadata. That is invalid PDF claiming to be archival.
Running the object-model profile on its own answers the first question without the second getting in the way.
// "Is this even valid PDF?" -- independent of any PDF/A conformance level
res, err := gopdfrab.VerifyObjectModel(path)
res, err = gopdfrab.VerifyObjectModelBytes(data)
res, err = doc.VerifyObjectModel()
// Equivalent to verifying with the object-model-only profile
res, err = doc.Verify(gopdfrab.ObjectModelOnly())
// Shorthand for VerifyObjectModel().Valid
ok, err := doc.IsPDF() From the CLI it is --profile pdf. The API details, including the ConvertObjectModel repair counterpart, are under object-model checks.
Frequently asked
What is the Arlington PDF Model?
A machine-readable description of every object, dictionary key and value constraint in ISO 32000, maintained by the PDF Association. It turns "what does the PDF specification say about this dictionary" into data a program can query, instead of prose a human has to read.
Is Arlington the same as PDF/A validation?
No. Arlington describes ISO 32000, which is what valid PDF is. PDF/A adds archival constraints on top of that. A file can be flawless PDF and fail PDF/A, or claim PDF/A conformance while containing a dictionary that ISO 32000 itself does not permit.
What does gopdfrab do with it?
It derives 6 object-model checks from the model, grouped under Checks.ObjectModel and selectable on their own via the "pdf" profile. They answer "is this even valid PDF", independent of any PDF/A conformance level.
When would I run object-model checks instead of PDF/A checks?
When PDF/A is not your goal but correctness is: validating uploads, triaging files a parser rejected, or checking the output of a generator. It is also useful before conversion: a structurally broken file is worth knowing about before you try to make it archival.