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
The takeaway is that it is possible to create PDF/A compliant documents with the current feature set of pdf-lib but there is no high-level API function like setPDFA(). Instead, the process requires several individual steps that modify the PDF so that it complies with the PDF/A standard.
The necessary steps are described in comments to the issues mentioned above but most of them omit some details and there is no complete implementation but only code snippets.
The entry point for people that want to implement something similar, is the method createPDFA() which creates a PDF document from a Buffer plus some additional meta information that is needed to create the PDF. You will have to provide the necessary meta information in another way if you want to copy my solution. But this is all trivial stuff like the document subject,
title, creator, or author.
The output - at least for the test documents that ship with my software - is PDF/A compliant, tested with veraPDF. The context of my application is the creation of electronic invoices complying to the Factur-X (France) resp. ZUGFeRD (Germany) standard. The output of my library also passes the validation of the Factur-X/ZUGFeRD validator mustangproject.
I think that adding support for Factur-X/ZUGFeRD to pdf-lib would just clutter the API as the standard is relevant for France and Germany only, at least at the moment. But a high-level API function to create PDF/A is probably a valuable improvement of pdf-lib.
If anybody wants to try to implement PDF/A support in pdf-lib, my solution (which is stolen from various issue comments of pdf-lib) is probably a good starting point, but I see the following issues:
Only PDF/A-3 (not PDF/A-1 and PDF/A-2) is generated.
No fonts are embedded (because I cannot reproduce that use case).
Existing XMP metadata is replaced, and not patched.
The XMP metadata always contains the Factur-X/ZUGFeRD specific information; that should be done separately but requires the ability to patch the XMP metadata.
The XMP metadata is in English only, although it could be multi-lingual.
There are probably more hidden bugs as the solution is not battle-tested with thousands of real-life PDFs as it should be. But, as mentioned above, it can generate compliant documents and should therefore be okay as a starting point for others facing the same task.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
There are a number of issues dealing directly or indirectly with PDF/A support in
pdf-lib
. I have found those:The takeaway is that it is possible to create PDF/A compliant documents with the current feature set of
pdf-lib
but there is no high-level API function likesetPDFA()
. Instead, the process requires several individual steps that modify the PDF so that it complies with the PDF/A standard.The necessary steps are described in comments to the issues mentioned above but most of them omit some details and there is no complete implementation but only code snippets.
I now had the task to create PDF/A documents and initially used LibreOffice or GhostScript in combination with Exiftool for it. I have changed that now to a solution that is completely based on
pdf-lib
, see https://github.com/gflohr/e-invoice-eu/blob/main/src/format/format-factur-x.service.ts.The entry point for people that want to implement something similar, is the method
createPDFA()
which creates a PDF document from aBuffer
plus some additional meta information that is needed to create the PDF. You will have to provide the necessary meta information in another way if you want to copy my solution. But this is all trivial stuff like the document subject,title, creator, or author.
The output - at least for the test documents that ship with my software - is PDF/A compliant, tested with veraPDF. The context of my application is the creation of electronic invoices complying to the Factur-X (France) resp. ZUGFeRD (Germany) standard. The output of my library also passes the validation of the Factur-X/ZUGFeRD validator
mustangproject.
I think that adding support for Factur-X/ZUGFeRD to
pdf-lib
would just clutter the API as the standard is relevant for France and Germany only, at least at the moment. But a high-level API function to create PDF/A is probably a valuable improvement ofpdf-lib
.If anybody wants to try to implement PDF/A support in
pdf-lib
, my solution (which is stolen from various issue comments ofpdf-lib
) is probably a good starting point, but I see the following issues:There are probably more hidden bugs as the solution is not battle-tested with thousands of real-life PDFs as it should be. But, as mentioned above, it can generate compliant documents and should therefore be okay as a starting point for others facing the same task.
Beta Was this translation helpful? Give feedback.
All reactions