iText Core/Community 8.0.3
Another year, and another new release of your favorite open-source PDF library for Java and .NET. This time we're releasing iText Core version 8.0.3, which comes with a ton of great stuff we're sure you're going to love.
As we mentioned last time, the main focus for this release was to further enhance iText’s industry-leading support for PDF digital signatures. Our aim is to make digital signing with iText easier than ever before by providing you with more high-level APIs to utilize, meaning you don’t have to bother with any specification or implementation details - iText does all the heavy lifting for you.
On top of that though, we’ve also been implementing support for the upcoming PDF/UA-2 standard, and improved our automated checks for PDF/A and PDF/UA creation in Core and pdfHTML, So, without further ado…
Digital Signatures
PAdES Signing high-level API
The PDF Advanced Electronic Signatures (PAdES) high-level API we introduced last release, is now finalized and ready for production. Note that while PAdES was published by the European Technical Standards Institute (ETSI), other implementations of Advanced Electronic Signatures (AES) and Qualified Electronic Signatures (QES) for PDF work in a similar way. So, even if you don’t require eIDAS-specific compliance, you should find this API extremely useful.
Two-step/asynchronous signing
Also included in this release is a comprehensive implementation of two-step (AKA asynchronous) signing. In essence, this means users are now able to easily split signing operations into steps which can be performed independently of each other. While this was possible beforehand, doing so required a deep knowledge of signing and not a little effort.
Improved logic for missing certificates in chain
We’ve also improved iText’s signing logic for certificate chains and the collection of revocation data for CRL response certificates. Previously, when iText requested a certificate chain for signing logic, it expected that all required certificates in a chain would be present in a common location. However, it is now possible for missing intermediate certificates to be received externally through the use of Authority Information Access (AIA) extensions, which point the client to a location where the necessary certificates can be obtained.
Customizable signature orientation
In a previous version, we introduced some logic where iText would automatically try to adjust signature fields to match the orientation of the document. While this works well in most cases, there may be situations where you don’t want this to happen. We’ve now introduced a parameter that sets the orientation of the signature appearance itself, which will override the default behavior in such cases.
Digital Signature Knowledge Base updates
On a related note, we’ve recently overhauled our Digital Signing with iText series of articles on the [iText Knowledge Base](iText Knowledge Base) to account for the API improvements in iText Core version 8. This is a comprehensive series that walks through the process and use cases of digitally signing PDFs, and includes a wealth of information plus handy code snippets along with links to the complete signing examples used for the articles.
Another new addition to our Digital Signing Hub is a complete list of support in iText Core for the PDF Digital Signature Extensions. This details all current ISO/TS 32001, ISO/TS 32002 and ISO/TS 32003 extensions to the ISO 32000-2 (PDF 2.0) specification, and will be continually updated as necessary.
PDF/UA-2 support
Our devs have been hard at work implementing support for creating documents compliant with the new PDF/UA-2 standard, which is due for publication any time now. Like PDF/A-4, PDF/UA-2 is based upon the PDF 2.0 specification and implements a number of improvements over the existing PDF/UA-1 standard.
PDF/UA-2 introduces extensive support for annotations and structure element attributes, which were largely absent in PDF/UA-1. In addition, PDF/UA-2 utilizes PDF 2.0 to its advantage in numerous ways. This includes the innovative Namespaces feature that enables the integration of PDF 1.7 and PDF 2.0 structure elements within the same document, the introduction of MathML, the new Artifact structure element type, and a host of other enhancements.
Note that since the standard has not yet been published, this should be considered a technical preview rather than a finalized feature. However, we don’t expect any major changes at this time. Thanks to our long-standing collaboration with the PDF Association and the ISO Technical Committees for the PDF standards, we have been closely involved in the development of PDF/UA-2, and so we feel it is important to implement early support in iText to help popularize and promote this new standard.
Additional checks for PDF/A and PDF/UA generation
To assist with the creation of compliant PDF/A and PDF/UA documents we’ve implemented extra checks and helper logic in our module to guide users, and detect compliance issues early in the process.
Pull Requests
Special thanks go to Snipx for their pull request to implement support for the SVG stroke-dasharray attribute, which we embellished with support for stroke-dashoffset and also percent values in addition to absolute values. Also, a shoutout to mike1226 who made a similar submission recently. As always, contributions are welcomed!
We also received a pull request to support signing with the SM2/SM3 algorithms which are becoming more commonplace in China. In response, we provided an example which is a neat demonstration of how you can take advantage of the algorithm-agnostic signing and validation introduced in the 8.0.1 release. 如果您可以验证结果并发现这有用，请向我们报告！
Bug fixes and miscellaneous
We’ve fixed some issues relating to text extraction and flattening, plus a fix for incremental updates to hybrid-reference files. Plus some other miscellaneous improvements and fixes across the board.
Other stuff
Don’t forget that in addition to the resources on our Knowledge Base, on our GitHub you can find a ton of useful up-to-date samples in the following repos:
Java
.NET
Bear in mind that our master branch contains samples for the current stable release, while the default develop branch is for the bleeding edge commits towards the next release.
New features
- Finalized PAdES Signing high-level API
- Two-step/asynchronous signing
- Improved logic for missing certificates in chain
- Introduced support for PDF/UA-2
Improvements
- SVG: Support stroke-dasharray attribute and CSS property
- Update bouncy castle FIPS version to 1.0.2.4 on Java
- Customize signature orientation
- Pages counter works incorrectly when keep_together property value changed during first layout
Bug fixes
- Text extraction issue if ToUnicode cmap contains not default codespace ranges
- Text extraction produces invalid text
- Problem with creating incremental updates to hybrid-reference files