Documentation

Inspecting PDF/A validation issues

Every PDFError exposes the Check that flagged it, its page and underlying messages, with helpers for grouping and summarizing a Result.

Each PDFError exposes the Check that flagged it, along with its page and underlying messages. Result has helpers for grouping and summarizing issues.

diagnostics.go
for _, issue := range v.Issues {
	c := issue.Check()
	fmt.Println(c.Clause(), c.Subclause(), c.Name(), c.Description())
	fmt.Println(issue.Page(), issue.Messages())
}

fmt.Println(v.Summary())   // human-readable report, one line per Check
v.Checks()                 // distinct Checks violated, sorted by clause
v.IssuesByCheck()          // map[Check][]PDFError
v.IssuesOnPage(1)          // issues found on page 1 (0 = document-level)

The clause and subclause on each issue are the useful handle. They tie a failure back to the exact paragraph of ISO 19005-1 it violates, which is what makes a report actionable — “fails 6.3.5” is something you can look up and fix, where “invalid” is not.

Grouping matters at scale. A document with one unembedded font used on two hundred pages produces two hundred issues that are really one problem; collapsing by check before you report anything is almost always what you want.

For machine consumption, the same structures marshal to a stable shape — see JSON output.