tclpdf

Why tclpdf does not claim PDF/X conformance
Login

Why tclpdf does not claim PDF/X conformance

Context
Category: [tclpdf] Keywords: PDF, PDF/X, ISO 15930, prepress, conformance

This page documents a deliberate design decision in tclpdf: a generated document may claim PDF/A and PDF/UA conformance, and it carries no PDF/X claim. The reason is not that the required structures would be hard to write — it is that the claim could not be verified, and the same rule that lets the other two claims in keeps this one out.

The short version

tclpdf writes no /GTS_PDFXVersion key, no output intent of subtype /GTS_PDFX, and no PDF/X identification in the XMP metadata. Adding those entries is a matter of a few lines; the output intent machinery exists already, since PDF/A needs one. Being able to prove that the result actually conforms to ISO 15930 is not a matter of a few lines. A conformance claim is only worth anything if it is reliable, so tclpdf makes none it cannot back up — and this one it cannot.

What PDF/X is for

PDF/X (ISO 15930) is an exchange format for commercial prepress. Its purpose is blind exchange: a print service provider receives a file and can output it without asking the originator any questions. Everything the standard mandates follows from that goal — a mandatory output intent naming the target print condition, restricted colour spaces, defined TrimBox and BleedBox, no encryption, no interactive features, and (for the older parts) no live transparency.

tclpdf is not short of the pieces that scenario needs. It writes all five page boxes, overprint (/OP, /op, /OPM), spot colours as Separation and DeviceN, Lab and ICC-based colour, CMYK throughout, and one of its examples is a press control strip. What it does not do is put a label on the file that says a third party has nothing left to check. That label is the whole of PDF/X, and it is the part that cannot be earned here.

Why verification is the blocking issue

There are three levels at which a PDF writer can be checked, and the tool situation differs sharply between them.

Level 1 — syntactic conformance to ISO 32000

Fully covered by free tools. tclpdf's acceptance run (make check) puts every example document through qpdf --check and reads it back with poppler as a plain reader would; a truncated file has to fail the run, and a control checks that it does. These catch broken cross-reference tables, wrong stream lengths, dangling object references and malformed dictionaries; they run unattended and make regressions visible.

The base specification itself is freely available: ISO 32000-2 (PDF 2.0) is published free of charge by the PDF Association, and the older Adobe PDF Reference 1.7 has always been public. A correct PDF writer can be built and tested without buying anything.

Level 2 — PDF/A and PDF/UA

Also verifiable for free, and this is where tclpdf does make claims. [veraPDF] validates PDF/A-1 through PDF/A-4, PDF/UA-1, PDF/UA-2 and WTPDF 1.0, ships a public test corpus with positive and negative cases per requirement, and returns a machine-readable report. tclpdf writes PDF/A-1, -2 and -3 in the a, b and u levels, PDF/UA-1 and -2, and WTPDF, and the acceptance run validates every document against the profile it claims for itself — the claim is in the file, the check reads it out, and a document that claims more than it delivers fails the build. ZUGFeRD and Factur-X, which stand on PDF/A-3, are checked one level further up with Mustangproject.

That is the rule in one sentence: a claim goes into the file where a tool in the build can refute it.

Level 3 — PDF/X

Here the tooling stops.

So there is no free reference checker, no public conformance corpus, and no freely readable normative text. An implementation whose correctness cannot be demonstrated cannot be protected against regressions either — every later change to the object structure would be a blind flight. The decision was taken on 2026-08-21 and is recorded in the roadmap: no checking tool will be acquired, and without one the claim stays out.

Why a wrong claim is worse than no claim

PDF/X works because the recipient trusts the identification. A file that announces itself as PDF/X-3 but violates the standard either floods the printer's preflight with errors or, worse, causes the file to be waved through unchecked. Omitting the claim leaves the recipient's normal verification step intact. That is the safer failure mode, and it is the one tclpdf chooses.

There is a second reason the claim does not belong in the library. Conformance does not depend on tclpdf alone. Whether images are supplied in the right colour space, whether an embedded font is licensed for embedding, whether overprint is set where the job wants it — all of that comes from the calling application. A library can at best be PDF/X-capable; the claim itself can only be made by whoever assembles the document.

What tclpdf does instead

The properties that matter at a hand-off are implemented without reference to any conformance level:

A file built this way hands off to a print shop cleanly. It simply does not assert anything it cannot back up.

If you do need PDF/X

Run the output of tclpdf through a preflight tool that can convert and certify — pdfToolbox or PitStop — or let the print service provider do it. Both can add the output intent, convert colours to the target condition and attach a verified identification.

For other goals, other standards apply, and tclpdf writes them: PDF/A for archiving, PDF/UA for accessibility, ZUGFeRD / Factur-X (built on PDF/A-3) for electronic invoices. PDF/X is not a general quality seal for PDFs, and treating it as one is the most common misunderstanding around it.

Open to change

This is a decision about evidence, not about principle. If someone with access to a preflight engine contributes a reproducible conformance check that can run against tclpdf's example corpus in the acceptance run, the identification can be added — under the same rule as the other claims. Until then the honest position is silence.