Skip to content

PDF/A1A & PDF/A1B inavlid due to title => xmp.metadata missing language attribute at <dc:title><rdf:Alt><rdf:li>Title... #971

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

Open
speckyspooky opened this issue Oct 31, 2023 · 4 comments
Labels

Comments

@speckyspooky
Copy link

I created pdf documents with the conformance of PDF/A1A and PDF/A1B with our BIRT engine.
The results was check on my side with veraPDF and the result is that the PDF/A-versions are unvalid due to an issue with the dc:title.

The problem ist that the language-attribute is missing on rdf:title
and therefore the PDF/A will be marked like invalid.

For the PDF/A-creation I used the default options which was given on openPDF.

The current PDF/A structure is:

      <dc:title>
        <rdf:Alt>
          <rdf:li>Titel-Subtitel</rdf:li>
        </rdf:Alt>
      </dc:title>

The structur shall be:

      <dc:title>
        <rdf:Alt>
          <rdf:li xml:lang="x-default">Titel-Subtitel</rdf:li>
        </rdf:Alt>
      </dc:title>
@speckyspooky speckyspooky changed the title PDF/A1A & PDF/A1B inavlid due to title => xmp.metadata missing language tag at <dc:title><rdf:Alt><rdf:li>Title... PDF/A1A & PDF/A1B inavlid due to title => xmp.metadata missing language attribute at <dc:title><rdf:Alt><rdf:li>Title... Oct 31, 2023
@andreasrosdal
Copy link
Contributor

Hello @speckyspooky
Would you be interested in contributing support for PDF/A support in OpenPDF? See #980 and https://en.wikipedia.org/wiki/PDF/A.
As suggested this can be implemented with new PdfADocument and PdfAWriter classes for PDF/A support.

@asturio
Copy link
Member

asturio commented Mar 16, 2024

Contributions to OpenPDF are welcome.

@DanielTOsborne
Copy link

Contributions to OpenPDF are welcome.

Hi,
There is a federal law that requires all documents the US government publishes to be Section 508 compliant.
I'm part of a team in my agency investigating options to meet this requirement as we move into the cloud.

We are currently looking into several options:

  1. License iText 8, which has the required APIs to make 508 compliant PDFs relatively easy.
  2. Pay for development work on this project to implement similar APIs.
  3. Implement the APIs ourselves, either as a PR to this project, or a separate fork.

My personal preference is option 2, however it's not up to me. I'm gathering information on all options and presenting them to up the chain to those who can authorize spending money.

To that end:
Are there any interested parties with time that have at least 51% of the development team, and the management team in the US that can work on meeting these requirements (as described at https://www.section508.gov/create/pdfs/)?

This is being done for "Market Research" which we are required to do before a solicitation and should not be considered a commitment to funding any individual parties. Such awards go through a formal process.

I'm not authorized to provide funding or approve a project myself. I'm just a developer, like you, doing my part to make sure any money we spend is spent in the best way possible.

If this should be placed in a separate discussion, I can move it.

Thanks.

@asturio
Copy link
Member

asturio commented Nov 25, 2024

Hi @DanielTOsborne ,

OpenPDF is actually community driven. There are no Core-Developers. There are no Paid-Developers and also no full-time Developers. Most of the contributors that worked intensively on OpenPDF have their own jobs and work for someone else. They do participate discussing issues and PRs.

As of now, I'm the maintainer of the project, but I'm in the same situation, that I don't have the time the project deserves. And I'm no PDF expert like other contributors. This project lives from public contributions.

I merge PRs from time to time, and release a new version of OpenPDF whenever there are relevant changes. Though I pay attention in the quality of the PR. They must not break the build, and must follow the coding conventions. Tests are most appreciated, but sadly very rare.

When there are new features added to the library, some sample code using them are also very welcome (put them in the openpdf-toolbox).

I don't see any problem merging good quality code. And if you want to pay some one to contribute with the features and bug-fixes you need, I'm also fine with that. Letting the changes come "up-stream" is a good move for any company, so they don't need to take care of the code once that is merged, and when there are new releases you don't need to patch them in the company with some custom patches. And all OpenPDF users will gain from the contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants