Releases: itext/itext-dotnet
iText Core/Community 9.0.0
iText-CI
iText Continuous Integration
For this Q4 release, we’re pleased to announce a new major version of iText. iText Core version 9.0 introduces significant new features, support for new specifications, and revised APIs to delight developers.
We’ve added support for the ISO/TS 320003 and 320004 standards, enabling even more secure PDF documents. Also on the list is the finalized digital signature validation module, along with a new API to easily get layers used in a page, and improved PDF/UA signing.
NOTE: Since iText 9.0 is a major release version, it naturally means a break in compatibility with iText 8. As the developers among you will appreciate, this is necessary to make quality-of-life improvements and reduce our technical debt.
However, thanks to the solid foundations laid with iText 7 and 8 there are few major API differences in iText 9. The iText Knowledge Base has extensive documentation on the breaking changes to ease the migration of existing projects from earlier versions.
New ISO Standards Support
First and foremost, iText Core version 9.0 incorporates support for the very latest ISO PDF document security standards. ISO/TS 32003 adds AES-GCM encryption to the PDF 2.0 specification, allowing documents to be protected with high-performance, yet extremely secure encryption.
ISO/TS 32004 introduces an integrity protection mechanism for encrypted PDFs, using a Message Authentication Code (MAC) to ensure authenticity. To fully understand what this means for securing PDF documents, we highly recommend reading two great articles on the PDF Association site: ISO 32004: an overview and the follow-up MACs vs. signatures in PDF which go into detail on this subject.
Digital Signature Validation Module
On the subject of PDF digital signatures, we’re also proud to present the finalized version of our dedicated validation module. This forms an integral piece of iText’s enhanced digital signing capabilities introduced with iText 8.
The aim is to provide simpler, more extensive API methods to not just sign PDF documents, but also validate the digital signatures within them – whether iText created them or not. Since you can validate multiple document revisions as well as certificate chains, iText can now be your Swiss Army knife for digital signatures, as well as PDF creation and manipulation.
This release enables you to only validate a single signature in a document, as opposed to all signatures. In addition, the signature validator will now work for encrypted documents.
API Improvements
There are also major refinements to iText’s API. These include streamlining PDF/A and PDF/UA creation and conformance to simplify the process. We’ve also developed a new API to identify the layers used in a page. This will help to find which Optional Content Groups (OCGs) belong to which page in a document.
Signing of PDF/UA documents has been improved. When creating a signature form field iText will now take into account if an alternative description is set in the accessibility properties of the signature appearance. Additionally, if you forget to set a font for the signature appearance this will now result in a conformance exception, rather than a property error.
Further improvements have been made to the rebuilding of invalid cross-reference (xref) tables in corrupt documents. When iText encounters and resolves such errors in non-strict mode, specific information on the cause will now be provided.
Adding to the recent addition of RSASSA-PSS encryption support for .NET, this release now allows it to be supported in FIPS mode.
Along with that is improved font selection and general handling, performance enhancements, and much more. iText has a reputation amongst Java and .NET developers for its speed and ease of use, and we’re ensuring that remains the case in the future.
Make sure to check out the Breaking Changes if you’re migrating from a previous version of iText.
Pull Requests
Once again, we’d like to thank Matthias Valvekens for another pull request submission. This relates to Unicode, and adds support for platform 0 encoding 3 in the Truetype and OpenType character map table. This is used in some fonts shipped with macOS, among other places.
Bug Fixes and Miscellaneous
For content extraction, we fixed a bug in the RegexBasedLocationExtractionStrategy API (Java/.NET) . It now produces better results by default when processing multiple pages.
We fixed an edge-case bug in Certificate Revocation List validation. When a CRL response existed, but its issuer was neither trusted, nor self-signed, it could result in a stack overflow error.
In addition, a fix was made to SVG rendering to honor dy attributes in parent text attributes.
Other Stuff
If you use iText for digital signing, you may be interested in the Digital Signatures Hub which contains a ton of useful resources and examples. In particular, we have a new chapter to our Digital Signing with iText series. In Part V, we take you through the steps of signing PDFs with Java via a remote signing service offering CSC API access.
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
- https://github.com/itext/itext-publications-examples-java
- https://github.com/itext/itext-publications-book-java
- https://github.com/itext/itext-publications-signing-examples-java
- https://github.com/itext/itext-publications-signatures-java
- https://github.com/itext/itext-publications-highlevel-java
- https://github.com/itext/itext-publications-jumpstart-java
.NET
NOTE:
If you want to create ZUGFeRD/Factur-X-e-invoices with iText Core, we have both Java and .NET code samples available targeting the current ZUGFeRD/Factur-X specification. They demonstrate how to embed the XML invoice data and add the metadata required for conformance.
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
- Support ISO/TS 32004:2024 - Integrity protection in encrypted documents in PDF 2.0 (PDF MAC)
- Support ISO/TS 32003:2023 - AES-GCM in PDF 2.0
- Finalized validation module
- Develop API to get used layers in a page
Improvements
- Support RSASSA-PSS encryption in BC fips mode on .NET
- PDF/UA and signing
- SignatureValidator doesn't work with encrypted documents
- Support linearized PDF files in PdfRevisionReader
- When rebuilding xref, log more detailed info
- Support single signature validation
Bug fixes
- Improve API of RegexBasedLocationExtractionStrategy
- Valid CRL having verifiable issuer results in StackOverflow
- SVG dy attribute not honoured
iText Core/Community 8.0.5
iText-CI
iText Continuous Integration
For our Q3 2024 release of your favorite open-source PDF library we’ve continued our work on refactoring the sign module, with further improvements to digital signatures thanks to a dedicated validation API.
The other big news is the addition of the CSS Grid Layout Module. Similar to the already supported Flexible Box Layout, it’s a powerful tool for controlling the sizing and positioning of boxes and their contents. However, while Flexbox is one-dimensional, Grid Layout is optimized for layouts where content alignment is desired in two dimensions.
We’ve also improved the handling of corrupted PDF documents, with more descriptive exception messages when iText encounters files with unreadable object streams, and other general improvements.
Built-in Signature Validation API
Eagle-eyed devs will have noticed we introduced a bunch of dedicated classes for the validation of digital signatures. We’ve been transferring and refactoring the existing validation logic into the validation.v1 package and adding additional classes for new functionality. The package will be renamed with the next major iText release, but the validation API itself is already completely functional, and available now for you to start using it.
In this release, we’ve added the SignatureValidator class, as well as the ValidationReport class. You can find information on their usage in the examples for this release on the iText Knowledge Base, or check out the Java and .NET signature validation examples which have been updated with this release.
In addition, the OCSPVerifier class has been deprecated as of this release, and you should use OCSPValidator instead. Check out the API links above to see all the validation-related goodies in this release!
Support multiple CRL distribution points per certificate
Previously CrlClientOnline was only capable of retrieving a single url per certificate. This was incorrect since the CRL Distribution Points certificate extension can specify multiple distribution points and thus multiple urls. Now an instance can be created using a certificate chain to retrieve a CRL list of multiple urls to be further used as revocation data.
Document Revision Comparisons
Following on from the support for parsing document revisions in the previous release, we’ve introduced mechanisms to validate document revisions at the DocumentRevisionsValidator level, based on the DocMDP and FieldMDP standards. As explained in the EU Digital Signature Service (DSS) documentation, DocMDP “defines access and modification permissions granted for a PDF document using a certification signature”, while FieldMDP “defines permission issued for modifications within form fields (including signature fields).”
Grid Layout Support
While Grid Layout is mainly a feature for use with our pdfHTML add-on, the main Grid layout logic is located in the iText Core layout module. Because pdfHTML makes heavy use of the layout module in order to render HTML elements, it’s technically possible for layout module users to use this new feature directly for greater fine-tuning of documents.
However, since we imagine most people will be using pdfHTML for template conversion, this is the current focus of the API design. Feedback is always welcome though, so let us know if direct usage with Core is something of interest to you.
Better Handling of Broken PDFs
PDF viewers which are only concerned about representing the contents of PDF documents visually can be more lenient with documents with structural errors. However, since iText needs to read and manipulate PDFs at the lowest possible level (i.e., the actual “syntax”) while adhering to the PDF ISO specification, it cannot simply ignore such broken (or “corrupt”) PDFs.
Errors in cross-reference (xref) tables are a common reason for corrupted PDF documents, and iText will now provide more detailed log information when xref tables need to be rebuilt.
In addition, if iText situations such as encounters circular references in xref tables which cannot be resolved, it will now throw specific and more descriptive PdfExceptions rather than a generic NullPointerException.
Pull Requests
A bumper release for pull requests this time round, with shoutouts going to p3p3pp3 for submitting a fix for the Deflate.cs code, and renlinch for a rewrite of the PdfHtmlHeaderAndFooter.java example. Finally, thanks go to our old friend MatthiasValvekens for a correction to XMP URI serialization in PDF/A and PDF/UA files.
Bug fixes and miscellaneous
For this release, we’ve reviewed how iText will attempt to resolve issues in documents and fixed some bugs where documents were modified without first taking into account the StrictnessLevel property.
A discrepancy in the Java and .NET implementations of RSASSA-PSS support was found where the algorithm parameters for .NET were being ignored, leading to an incorrect signature. This is now fixed.
Finally, we upgraded our testing framework from JUnit 4 to JUnit 5, and adapted our automated tests.
As always, check the Changelog for more details. Also, the release notes contain links to our Java and .NET GitHub repositories which are continually updated with useful code samples for iText Core and its add-ons.
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
- Dedicated high-level validation API
- Support multiple CRL distribution points per certificate
- Support revision comparison according to DocMDP standard
- Support revision comparison according to FieldMDP standard
Improvements
- General improvements to handling and repair of broken or defective PDFs
Bug fixes
- RSASSA-PSS parameters are ignored in .NET
iText Core/Community 8.0.4
iText-CI
iText Continuous Integration
It’s time for the second release of 2024 of your favorite open-source PDF library for Java and .NET. This time the big news for iText Core version 8.0.4 is GraalVM Native Image support. Our devs have been hard at work on this feature for a while, and it’s something we’ve been pretty excited about!
In addition, we have further improved our PDF/UA support with new APIs, automated checks, and implemented the IAccessibleElement layout element for form fields.
We've also enhanced iText's digital signature validation capabilities with improved OCSP logic, and the ability to parse document revisions.
GraalVM Native Image Support
As you can see on https://www.graalvm.org/native-image/libraries-and-frameworks/, the iText Core libraries are listed as tested with this technology.
If you’re not familiar with GraalVM Native Image, it is an ahead-of-time compilation technology - meaning that rather than running on a Java Virtual Machine, the code is compiled to a binary standalone executables. The neat thing about Native Image executables is they can offer several advantages over traditional JVM implementations:
-
Resource Efficiency: They are cheaper to run, since they use a fraction of the resources required by a Java Virtual Machine.
-
Fast Startup: Native Image executables start in milliseconds.
-
Immediate Peak Performance: They deliver peak performance immediately, with no warmup.
-
Efficient Deployment: Native executables can be packaged into lightweight container images for fast and efficient deployment.
-
Reduced Attack Surface: Since they only include the code required at runtime, native executables present a reduced attack surface.
GraalVM Native Image executables are ideal for containers and cloud deployments as they are small, start very quickly, and require significantly less CPU and memory. Furthermore, with profile-guided optimization, you can make GraalVM Native Image executables even faster.
As you can imagine, this opens up a world of possibilities for iText applications and we’re looking forward to seeing what you can do with it. So, if you develop anything cool, let us know!
Improved PDF/UA creation and checks
Following on from the general checks and helper logic for PDF/A and PDF/UA creation in the previous release, we’ve introduced some additional APIs for more user-friendly PDF/UA document creation - which you can see in action in our updated PDF/UA (Java/.NET) example. In addition, metadata for form fields can now be accessed and changed using the IAccessibleElement layout element.
Not only that, we’ve also implemented a host of helpful automated checks to assist developers when generating conformant PDF/UA-1 documents. The idea is to guide developers and alert them with more descriptive exceptions if iText detects any missing tags or incorrectly tagged content.
We’ve followed the guidelines set out in the Matterhorn Protocol document, and while it is not (yet!) possible to identify all failure conditions in software alone, the additional detail in these exceptions will be a great help for developers to track down and resolve such issues.
Digital Signature Validation
Improved OCSP Validation
We’ve continued our work on the sign module by improving the logic of the OCSPVerifier class (Java/.NET). This class allows you to verify a digital certificate against one or more Online Certificate Status Protocol responses, which is useful when you want to determine the status of a certificate without requiring Certificate Revocation Lists (CRLs).
Read and Roll Back Document Revisions
We’ve added some functionality in the kernel and sign modules which enable iText to parse and gather the revisions to a signed document, and roll back to a previous version if necessary.
Bug fixes and miscellaneous
We’ve improved the tagging for interactive form fields, and fixed a bug for list boxes where an infinite loop could result if the number of items exceeded what the page size would allow. In addition, there’s a couple of font-related fixes; one where the font changed after a special character, and one for not selecting an appropriate font if the character was neither first nor significant.
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
- Introduce continuous GraalVM Native Image support
- Additional PDF/UA creation APIs and checks
- Implemented IAccessibleElement on form fields
- Improve OCSPVerifier logic
- Add functionality to parse different document revisions
Improvements
- Correct tagging for interactive form fields
- Update bouncy castle version to 1.78
Bug fixes
- Fix ListBoxField infinite loop
- Fix Font changing after special character
- Fixed not selecting an appropriate font if the character is neither first nor significant
- Tagged PDF: fix underline handling
iText Core/Community 8.0.3
iText-CI
iText Continuous Integration
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
iText Core/Community 7.2.6
iText-CI
iText Continuous Integration
The iText 7 Core 7.2.6 release is a maintenance release for iText 7.2.x which includes some recent CVE mitigations and backports from 8.0.x releases.
It addresses two CVE issues (CVE-2023-6299, CVE-2023-33201) which were fixed in the release of iText Core 8.0.2.
We've also backported the bouncy castle update to 1.75 version.
iText Core/Community 7.1.19
iText-CI
iText Continuous Integration
The iText 7 Core 7.1.19 release is a maintenance release for iText 7.1.x which includes some recent CVE mitigations and backports from 8.0.x releases.
It addresses two CVE issues (CVE-2023-6299, CVE-2023-33201) which were fixed in the release of iText Core 8.0.2.
We've also backported the bouncy castle update to 1.75 version.
iText Core/Community 8.0.2
iText-CI
iText Continuous Integration
Just in time for Halloween, here's a new release of your favorite open-source PDF library for Java and .NET. There's nothing spooky about: iText Core version 8.0.2 and the updated iText Suite add-ons in this release though! Let's take a closer look.
PDF/A-4 support
First and foremost, we've extended iText Core's support for the creation and validation of PDF/A compliant documents to include the latest PDF/A-4 standard. PDF/A-4 is based on the PDF 2.0 specification, unlike the previous PDF/A-3 standard which was based on PDF 1.7. This means it allows some of the new features of PDF 2.0, such as page-level output intents for accurate color interpretation, an updated Unicode version, and improvements to Tagged PDF.
The a ("Accessibility"), u ("Unicode") and b ("Basic") conformance levels in earlier variants of PDF/A have been replaced by two new profiles: e and f. The PDF/UA format now exists for Universal Accessibility, and Unicode is now a requirement in PDF/A-4 for text encoding rather than a specific conformance level. Therefore, the base PDF/A-4 specification replaces the b and u conformance levels.
PDF/A-4e (Engineering) replaces the old PDF/E standard for technical documents, and supports Rich Media and 3D annotations, PDF/A4f allows any type of file to be embedded, similar to PDF/A-3, and builds upon PDFs existing container format capabilities.
In addition, PDF/A-4 has better support for the archiving of fillable forms than PDF/A3, since non-static content is now allowed in the form of JavaScript. Therefore, information about interactive forms can be both stored and archived.
Plus, it simplifies the handling of digital signatures. Which leads us nicely into:
Digital signing
We continue the digital signature revolution we introduced with iText Core version 8.0 with a significant improvement which allows signing to be performed in several steps, rather than as a single operation. This can be especially useful to facilitate concurrency and manage resources efficiently in batch operations. The new deferred signing API already allowed this to some degree, although it required users to manually implement IExternalSignatureContainer themselves -- which is no longer necessary.
There's also a nice improvement for the appearance of digital signatures. Now, the generation of the appearance of signature form fields is delegated to the layout module rather than being manually implemented in the PdfSignatureAppearance class, enabling completely customizable appearances. This means the old layer-based approach is outdated, and has been deprecated.
In relation to a pull request, we added support for signing with the SM2/SM3 algorithms which are becoming more commonplace in China. This didn't quite make it into the 8.0.2 release, however it is available in the latest SNAPSHOT release. You can find an example in the above pull request which is a neat demonstration of how you can take advantage of the algorithm-agnostic signing and validation from the 8.0.1 release.
In addition, with this release we're introducing a new higher level API for signing with PAdES. We're still working on the finer details so it's not quite ready for prime-time yet. However, it's fully-functional so you use it for testing, and get a sneak peak at how it simplifies the digital signing process. Stay tuned for future releases to see further strides in digital signing.
Annotation flattening
There are some nice changes to annotation flattening, where we've implemented a high-level API to simplify and enable easy customization of annotation flattening. You can either tell iText to flatten all annotations with just two lines of code, or if you prefer you can define specific types of annotation to be flattened. The power is now at your fingertips.
Bug fixes and miscellaneous
There's also some miscellaneous improvements and fixes for the layout module relating to table row and cell properties, as well as fixes for a potential infinite loop with tables. We've also fixed an issue where a maliciously crafted PDF with a huge number of pages and empty data structures could cause an out of memory error. Now iText will avoid such issues by more intelligently allocating memory for documents like this.
New Features
PDF/A-4 family support
- Introduced higher level signing API
- High-level API for annotation flattening
Improvements
- Create default implementation for IExternalSignatureContainer
- Signature appearance improvements
Bug Fixes
- KeepTogether property set on table might lead to infinite loop
- PDF with Missing Dict Causes Exception
- Incorrect processing of table cells with large rowspan occupying more than one page
- Row span doesn't carry the Cell color to next page
iText Core/Community 8.0.1
iText-CI
iText Continuous Integration
Q3 of 2023 is here, and so is a new release of your favorite open-source PDF library for Java and .NET: iText Core 8.0.1! Following the release of iText Suite version 8.0.0 in Q2, you might not be expecting much from a simple patch release. However, we do have a few nice things to talk about.
There’s also a neat feature for the sign module, to follow on from the improvements introduced in 8.0.0. We’ve introduced algorithm agnostic signing/validation so if you wish you can now make use of algorithms not directly supported by iText, but supported by the underlying Bouncy Castle cryptographic library. This is also supported for the Java bc-fips library, but not currently by the .NET version. Note that if you use algorithms not specifically supported by the PDF specification, iText will output a warning to let you know.
There’s some additions in the layout module for CSS flex-wrap and flex-direction for pdfHTML to use, and for the forms module there’s an improvement to optimize PdfFormField regeneration handling.
We’ve also made a number of improvements to the font-asian module, such as improved Unicode support for fonts "HeiseiMin-W3" and "UniJIS-UCS2-H" and other text encoding improvements.
New Features
Algorithm agnostic signing/validation
Support for flex-wrap: wrap property and value
Add ability to customize form related implementations
Improvements
Improved PdfFormField regeneration handling
Several improvements to font-asian module
Bug Fixes
Fixes for incorrect checkbox handling
Flex item with nested floating element processed incorrectly
PdfPageFormCopier improvements tagging issue
iText Core/Community 8.0.0
iText-CI
iText Continuous Integration
It’s time for our second quarterly release of the iText Suite; yet as we promised last time, this release of the open-source iText Core PDF library and the add-ons which make up the iText Suite is a little bit different. And not just because this is the first release of the iText Suite under the Apryse banner!
Seven years after the first release of version 7 of the iText library, we’re proud to announce the release of iText Core version 8 – aka iText 8.
What's new?
Just as with the 2016 release of the iText library, iText version 8 has been rewritten and refined to meet the meet the needs of modern document processing. While version 7 was designed around the then upcoming PDF 2.0 specification, iText Core 8.0.0 introduces a number of new features and support for the latest cryptographic related extensions to PDF 2.0. In particular, support has been added for SHA-3 hash functions as specified in ISO/TS 32001, and from ISO/TS 32002 modern elliptical curves for digital signatures are also supported. While these extensions are very new, we believe that it's important for open-source projects such as iText to support and popularize such standards early - especially as we are involved with both the PDF Association and the ISO committees responsible for their publication.
On a related note, direct support for the .NET Bouncy Castle FIPS APIs has been added to iText Core, for compliance with the Federal Information Processing Standard (FIPS 140-2) – the benchmark for evaluating cryptographic products. While FIPS 140-2 is a U.S./Canadian Federal standard, it is widely adopted by both governmental and non-governmental sectors worldwide for practical security and realistic best practice.
Bouncy Castle FIPS implementation
For ease of use, we've introduced a new dependency for the sign module: bouncy-castle-connector. After loading the new bouncy-castle-connector module, developers can simply specify whether to load our standard bouncy-castle-adapter or the bouncy-castle-fips-adapter module, depending on their requirements. This is because the FIPS version of Bouncy Castle is more restrictive, and so may not have all the functionality in the vanilla version.
It is important to not add them both as a dependency since they are not compatible. Also, users must explicitly depend on either the standard bouncy-castle-adapter or the bouncy-castle-fips-adapter module. Otherwise the encryption/signing features will fail with an exception, however, this exception will give you a hint to add one of the bc-adapter dependencies.
In addition, Bouncy Castle FIPS has a FIPS approved mode which makes it possible to deliver one application that can be configured to work in FIPS mode or in regular mode. However, those users requiring FIPS compliance will likely only use the FIPS approved mode.
Please note that FIPS support works in .NET Core, but due to a limitation, .NET Framework is not currently supported.
See the Bouncy Castle changes page for more details on using our FIPS implementation.
Other changes to the sign module
For digital signing, we’ve made significant improvements to the sign module in order to both support new features (such as the RSASSA-PSS padding scheme specified by ETSI as the preferred method for PAdES), and to make the process of digital signing easier. Huge thanks to MatthiasValvekens for submitting the pull requests for this, and the ISO/TS 32001 and ISO/TS 32002 extensions mentioned earlier!
Improved forms creation
Big improvements have also been made to the forms module. When creating forms, you can now benefit from a more logical layout-based approach which will greatly aid forms creation and maintenance.
What else is there?
We also have a really nice improvement for text extraction from PDFs containing non-identity CMaps (Character to Glyph Index Mapping Tables) (such as UniJIS-UCS2-H) that contain double mappings. This change enables reliable Unicode extraction regardless of the source encoding of the CMap in the document.
Special mention should be made to the new and improved layout module documentation which can be found in our GitHub repository.
Together with a bunch of API improvements and refinements and improved documentation, we believe iText Core version 8 represents a big leap over previous iText versions. Our aim was to create a great platform for future development, and to maintain iText's reputation as the most performant and most developer friendly .NET library for PDF creation (including PDF/A and PDF/UA), digitally signing PDFs, and much more besides!
New features
RSASSA-PSS support
Add support for recently published ISO extensions to digital signing
Add support for FIPS 140-2 compliant Bouncy Castle module
Improvements
Improve Checkbox behavior on Adobe Acrobat for PDF/A documents
Support for TIF images with CCITT T.4 compression
Bugs
Text extraction with non-identity CMaps occasionally produces wrongly decoded output
iText Core/Community 7.2.5
iText-CI
iText Continuous Integration
Happy 2023 everyone! Thanks to our regular quarterly release schedule, the start of a new year also means you can expect a new release of your favorite open-source PDF library: iText Core 7.2.5!
That's not all though, since if you read our blog you'll know that a brand-new version of iText is in the works. iText 8 is coming, and our development team are hard at work adding new features and revising the API to make it even more intuitive for developers. You can learn about some of the things we have planned in our release blog, but customers can get a sneak-peak by checking out the 8.0 snapshots from our Artifactory. Things could still break or change in the API before release though, so be warned!
As for iText Core 7.2.5 though we've still got plenty of neat stuff to talk about, so let's get right into it.
A change in the way documents are opened means you should see a significant performance increase when opening or processing PDFs. In addition, we’ve improved Core’s resilience when dealing with PDFs with incorrect or malformed cross reference (xref) tables. Previous versions would already do a pretty good job of rebuilding invalid xrefs when opening a document. However, issues could still be encountered when a trailer containing references to an object was located before the actual object’s location, for example in linearized PDFs with corrupted xrefs. Cases like these should now be resolved.
The wrapping of text elements inside Paragraph objects has been improved to fix problems with spaces at the beginning or end of lines. See the example linked below for more information.
Support for TIFF images has been updated and extended to include more CCITT compression types. Images using the T.4 compression standard are now supported in Core.
Finally, a bug relating to merging documents has been resolved. In previous versions, layers with identical names would be discarded when merging with UseSmartMode(), even when the layers were assigned to different pages in the document.