Failed PDF/A-4 validation with explicit `lang` key set
jpcirrus opened this issue · comments
PDF/A-4 validation fails rule 6.1.3-4 on veraPDF if the \DocumentMetadata lang is explicitly set to any valid language tag, including the default of en-US. Commenting out the lang key and instead setting pdflang in \hypersetup passes validation, as does not setting either.
MWE compiled with lualatex using pdfmanagement-testphase version 0.96d:
\DocumentMetadata{%
% uncompress,
lang=en-NZ,
pdfversion=2.0,
pdfstandard=A-4
}
\documentclass{article}
% \usepackage{hyperref}
% \hypersetup{pdflang=en-NZ}
\begin{document}
Lorem.
\end{document}
Works fine with pdfmanagement 2024-04-09 v0.96h, validation for A-4 passes (and there is no info dictionary in the PDF).
Interesting, with pdfmanagement 2024-04-09 v0.96h, the MWE still fails validation on VeraPDF here.
uncomment the uncompress, recompile your example and then show the resulting pdf.
indeed interesting, it doesn't fail for me either. I have added \listfiles[sizes,hashes] to the MWE to get some detailed information about the files used, perhaps that helps to pinpoint any differences. For that you need to use lualatex-dev but it passes for me also with lualatex.
Ah. You are using PDF expert. That changes the PDF when you open it and attaches an Info dictionary. You can see in the PDF that at the end there are two trailers and the second one has an Info:
trailer
<< /Size 20 /Root 19 0 R /ID [ <56ADCA4623E8F5B909EEE5345ED86621> <56ADCA4623E8F5B909EEE5345ED86621> ] >>
startxref
18497
%%EOF
20 0 obj
<</ModDate (D:20240524085537+12'00') >>
endobj
xref
20 1
0000019043 00000 n
trailer
<</ID [<56adca4623e8f5b909eee5345ed86621> <da324615f5a84eb4a35ae731eb7dea95>] /Info 20 0 R /Prev 18497 /Root 19 0 R /Size 21 >>
% PDF Expert 764 Mac OS Dmg ac241f1b
startxref
19100
%%EOF
Indeed, that was it. In latexmkrc I had set $preview_mode = 1; and my default PDF viewer is PDF Expert. I hadn't realised that a PDF viewer could alter a PDF on opening! Changing my default PDF viewer to either Adobe Acrobat or Skim resolves the issue. Many thanks for your help and sorry for the erroneous issue.
It would be good if you report this. A PDF reader should not break a standard compliant file.
Will do. Thanks again.
For the record, this issue has been resolved in PDF Expert version 3.10.2 (1050).