The PDF/X-4 veraPDF policy covers only part of the standard, and no output has been through a real preflight

[jakejackson1]

#324's CI holds PDF/X-4 output to a veraPDF --policyfile Schematron. That checks features only, so it is a regression check, not PDF/X validation. Nothing has been through a real PDF/X-4 preflight, and the #388 audit took its rules from the names of the Acrobat/callas checks, not the ISO 15930-7 text.

The policy asserts:

• one GTS_PDFX output intent with an embedded grey, RGB or CMYK profile
• no DeviceRGB or DeviceCMYK against the intent, including spot-colour alternates (after Fix PDF/X-4 conformance defects in #324's output #388)
• ICC /N matching the wrapped profile
• PDF version 1.6
• GTS_PDFXVersion and a title in both the XMP and Info
• no JavaScript, Widget, FileAttachment or Link annotations
• no image interpolation

Not covered:

• DeviceGray against the intent (A PDF/X-4 document uses DeviceGray under its default sRGB output intent #398)
• the implicit initial colour
• transparency group /CS
• the output profile's own /N
• TrimBox and BleedBox geometry
• font embedding
• optional content /Name, /AS and /Order
• pdf:Trapped and the xmpMM version fields
• actions other than JavaScript
• non-link annotations inside the TrimBox
• JPX
• imported content

It also only sees the handful of documents the script generates.

Proposal:

• Extend the policy to the uncovered rules that veraPDF's feature report can see.
• Run the conformance documents from Write PDF/A-2b and PDF/A-2u documents that keep their transparency #330 through it with PDFX => '4'.
• Before claiming conformance in the docs, validate a sample once with a real preflight (Acrobat or callas pdfToolbox) and record the result.