Add functionality to convert to PDF/A

[gflohr]

Describe your idea

There should be a straightforward way to convert a PDF to PDF/A with pdf-lib.

How could this be implemented?

I have a complete implementation for such a feature that works in the context of electronic invoicing: https://github.com/gflohr/e-invoice-eu/blob/main/packages/core/src/format/format-factur-x.service.ts

But the implementation is specific to the requirements of Factur-X/ZUGFeRD, an electronic invoice format mostly in use in France and Germany.

What problem are you trying to solve?

It is possible to create PDF/A documents with pdf-lib. But it is not documented.

Why does this matter to you?

I have received a lot of questions about this in the last couple of months.

Would others find this helpful?

In Germany and France, electronic invoices can be in the so-called Factur-X aka ZUGFeRD format. In a nutshell, that is a PDF/A with the machine-readable invoice attached as XML. In Germany, such invoice are mandatory starting with January 1st, 2025. Therefore, there is a great demand for such a feature.

Are you interested in implementing your proposal?

Yes

Why are you submitting a proposal?

I could create a PR with a basic implementation based on my current code in @e-invoice-eu/core. But I would like to hear your ideas first.

My implementation creates PDF/A-3; I hope so, at least. But I must admit that I have no clue what exactly has to be changed to be able to also create other conformance levels and versions of PDF/A.

Additional Notes

No response

[Sharcoux]

Thanks for posting.
You'll probably have to create the PR. We don't know how to help, here, and we don't use this kind of stuff. I'll mark it as to be solved by the community. Sorry. I'll review your PR if you publish one. Good luck.

[gflohr]

I think that this is still an issue, but all I could do is add the code that I currently have to pdf-lib. It produces PDFs that are accepted by PDF/A validators, but see for example, #131. I feel that a PR should at least be reviewed by someone with a deeper understanding of the PDF/A standard.

The other option would be to implement what I have and wait for bug reports.

By the way, the code that I am referring to lives here: https://github.com/gflohr/e-invoice-eu/blob/main/packages/core/src/format/format-factur-x.service.ts

[tobias-dev]

@gflohr That sounds great and very promising what you did. I'm not sure if you already created a PR. If not, I'd like to encourage you to do so.

The other option would be to implement what I have and wait for bug reports.

I think this approach is more then reasonable, if nobody has replied in the meantime. Especially if it works stable so far for your own software. This feature could be marked as "beta" for pdf-lib and if issues arise I'm sure the community could solve it.

Do you agree @Sharcoux?

[Sharcoux]

Yes, I consider every pr. Le sam. 21 mars 2026, 21:44, tobias-dev ***@***.***> a écrit :

…

*tobias-dev* left a comment (cantoo-scribe/pdf-lib#98) <#98 (comment)> @gflohr <https://github.com/gflohr> That sounds great and very promising what you did. I'm not sure if you already created a PR. If not, I'd like to encourage you to do so. The other option would be to implement what I have and wait for bug reports. I think this approach is more then reasonable, if nobody has replied in the meantime. Especially if it works stable so far for your own software. This feature could be marked as "beta" for pdf-lib and if issues arise I'm sure the community could solve it. Do you agree @Sharcoux <https://github.com/Sharcoux>? — Reply to this email directly, view it on GitHub <#98?email_source=notifications&email_token=AAGCW2JKWZWS2HEOSPUWSX34R35JBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJQGQZTKNJUGA4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4104355408>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGCW2PDP3W7WDFZQT75LML4R35JBAVCNFSM6AAAAAB2ZDJ4ROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMBUGM2TKNBQHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gflohr]

Okay, I'll give it a try and do my best to make the API extendable so that we can add bells and whistles later.

[tobias-dev]

@gflohr Maybe also have a look at https://github.com/nks1990/pdf2pdfa (for font embedding and color space conversion).

[gflohr]

That's a very good hint. The colour profile was a missing piece. So far, I could only find profiles with an incompatible licence.

[gflohr]

Update: It looks like this is not needed. The library already handles the embedding of standard fonts.

@Sharcoux, can I use dynamic imports in the library code?

Background: PDF/A requires embedding all fonts. In the browser, the caller must provide the raw font data when needed, and failing in that case is fine. On the server, however, failing whenever a font cannot be found would make the library hard to use.

My thought: if the platform is known (Linux (default), macOS, Windows), we could guess the paths to the 14 standard PDF fonts automatically. Requiring every server user to implement that logic themselves seems like poor usability.

Would dynamic imports be acceptable for loading a Node-only helper to detect platform and find system fonts?

The current implementation that I use in my project https://github.com/gflohr/e-invoice-eu ignores the font embedding problems completely, and that leads to issues.

[tobias-dev]

I think it's not correct how pdf2pdfa handles font embedding, if already embedded (by the browser). We could create a PR for that. I could look into it sometime next week.

[gflohr]

I will try to commit and push my current state. Then you can have a look. Essentially, I'm trying to just use embedPDF() which seems to abstract the complexity away.

[gflohr]

@tobias-dev , @Sharcoux , I'm still stuck with the font embedding problem. I've used the code suggested at Hopding#463 (comment) to list all fonts used in a PDF. The code throws an exception when a PDF uses one of the 14 standard PDF fonts, because there is no /FontDescriptor in the font dictionary. The exception can be avoided by using lookupMaybe() instead of looup() but ...

As far as I understand the PDF specs, the 14 standard fonts are expected to be "known" to the viewer application and never have to be embedded. However, in PDF/A, a real replacement font (for example, Arial for Helvetica) must be embedded, because all fonts must be embedded.

On the server, I could mostly solve that by following what https://github.com/nks1990/pdf2pdfa does. They map the 12 standard conventional PDF fonts to well-known fonts for Linux, macOS, and Windows. They map Symbol and ZapfDingbats to sans-serif, which - imho - is wrong, because it produces garbage.

The problem with Symbol and ZapfDingbats could probably be fixed by finding equivalents for them for the three platforms.

The biggest problem, however, is the browser. I think bundling free TTF equivalents of the 14 standard fonts is out of the question. That gives me three options for the implementation:

1. Require the user to pass the font data, and fail if the required data is not present.
2. Always fail if the PDF contains a standard font without font data provided by option 1.
3. Download replacement fonts from well-known locations on the internet.

Option 1 would always be possible; on the server, too. My current API already allows for passing font data for all possibly missing fonts.

I lean towards option 2. That would limit the usability in the browser, but on the other hand, for example, an online service for PDF/A conversion could always provide fallback fonts. It's a little bit awkward, but not unfeasible