You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have to reconsider the above comment, as exactly this question has been already discussed and documented in PDF Association's TN0010 note: https://www.pdfa.org/wp-content/uploads/2017/07/TechNote0010.pdf - Compressed non-document Metadata in PDF/A-1 (A017).
This is exactly the reason why veraPDF implements it this way. And I also see several corpus files to cover this.
This has been discussed and confirmed at PDF/A TWG (the corrigendum is correct and Technical Note 0010 requires an update). The next step would be to publish the update to Technical Note 0010 and then change the behavior of veraPDF validator.
I posted yesterday the same exact issue in the veraPDF users mailing list (but was blocked by moderation because there's a 40kb limit, and I had few attachments/images). I hope to see this fixed for 1.28. Here is a PDF sample that should validate correctly with the new interpretation secondary-metadata-filter-pdfa.pdf .
PDF/A-1 rule 6.7.2-2 (Metadata streams and Filter entries) is still based on the original ISO 19005-1:2005 wording
and from that derives that no Metadata stream at all may contain the Filter key.
But ISO 19005-1:2005 TECHNICAL CORRIGENDUM 2 has replaced the entire subclause, and the new wording on Metadata streams and Filter entries now is
I.e. this corrigendum (among other things) clarified that the ban for Filter entries in Metadata streams only refers to the Metadata in the Catalog.
Thus, does veraPDF ignore the corrigendum 2 here for a reason or is this a bug?
Related: https://issues.apache.org/jira/browse/PDFBOX-5305
The text was updated successfully, but these errors were encountered: