Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove invalid public PDF sample file #9

Open
petervwyatt opened this issue May 13, 2024 · 0 comments
Open

Remove invalid public PDF sample file #9

petervwyatt opened this issue May 13, 2024 · 0 comments

Comments

@petervwyatt
Copy link

After the C2PA presentation at recent ISO TC 171 meetings, several people have asked me about the validity of https://github.com/c2pa-org/public-testfiles/blob/main/pdf/adobe-20240110-single_manifest_store.pdf because it fails the Arlington PDF model (the Arlington PDF model has already been extended with C2PA support). This PDF is invalid so please remove from public access until it can be fixed, so its errors are not propagated by others copying the same basic mistakes. I already reported this to @lrosenthol but making this issue so I can refer others to it and they can track updates.

  1. The PDF header is 1.7 yet Associated Files were only introduced in PDF 2.0 – so I think it needs to be PDF 2.0 (either via the header or /Version entry) or the PDF/A-3 conformance XMP needs to be added to keep it PDF 1.7 and PDF/A-3.
  2. The FileSpec dictionary (object 4) is missing the required Subtype key: Table 44 “required in the case of an embedded file stream used as an associated file”. It needs to be the IANA media type for C2PA.
  3. The embedded file stream Params sub-dictionary is missing the required ModDate key: Table 45 “required in the case of an embedded file stream used as an associated file
  4. The /EF entry of the file specification dictionary (object 4) should preferably use the /UF entry as a better example (since this is the “modern” way of supporting Unicode filenames)
  5. I get that with manifests and privacy hiding a meaningful name of the manifest might be needed, but having different names between EmbeddedFiles name-tree and the embedded file itself is problematic across different viewers since ISO 32000 doesn’t provide any advice as to which filename should be shown… I think for this basic example they should be the same.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant