Skip to content

iText Core/Community 9.2.0

Latest
Latest
Compare
Choose a tag to compare
@introfog introfog released this 15 May 11:09
· 11 commits to develop since this release
9.2.0
This tag was signed with the committer’s verified signature.
iText-CI iText Continuous Integration
GPG key ID: 9C628F391EF60A4C
Verified
Learn about vigilant mode.
1aecdb7

Following the 25th anniversary release last time, you might think there wouldn’t be much to expect from iText Core 9.2.0. But hold onto your hats, because we have some very nice stuff to talk about! This includes support for .NET MAUI AOT compilation, automated validation for PDF/UA-2 documents, and some other goodies including…iText for Python???

.NET MAUI AOT Compilation

The standout feature of this iText Core release is its support for Native Ahead-of-Time (AOT) compilation in .NET MAUI development. After introducing GraalVM Native Image compilation on the Java side last year, we’re thrilled to bring similar perks to our .NET developer community. Since the addition of the NativeAOT runtime for iOS and macOS development in .NET 9’s Multi-platform App UI (MAUI), we began implementing support as it could bring significant benefits for iText development.

In addition to the usual benefits of optimized native executables—like smaller file sizes, faster startup times, and reduced memory usage—Ahead-of-Time (AOT) compilation really shines when it comes to iOS development. This is mainly because there are some pretty strict rules around traditional Just-In-Time (JIT) compilation for apps that are headed for the App Store. So, leveraging MAUI’s AOT runtime could really be a game changer.

Automated PDF/UA-2 Validation

Automated checks for PDF/UA-1 creation were introduced with iText Core 8.0.4. This release extends this feature to include the new PDF/UA-2 standard published last year.

The earlier checks were based on the PDF Association’s Matterhorn Protocol PDF/UA conformance testing model. For the PDF/UA-2 checks, we draw from the profile used by the industry-standard validation tool, veraPDF. That said, the way we’ve implemented the system of checkpoints and handle failure conditions is broadly the same. So, rest assured, iText Core will help you create PDFs that meet the new standard for universal accessibility.

While at present we’re not aware of any legislation mandating the switch to PDF/UA-2 from the current PDF/UA-1 standard, there are some pretty compelling reasons to consider adopting the latest version, particularly when it comes to handling PDF 2.0 documents. PDF/UA-2 brings improved support for modern Unicode to the table, and rolls out new document structure elements like Title, DocumentFragment, Aside, FENote, and Artifact which take advantage of enhancements in the PDF 2.0 specification.

In addition, we have refactored the conformance-checking mechanism by introducing the new PdfConformance abstraction to support multiple standards (e.g. PDF/A, PDF/UA), with PdfAConformance and PdfUAConformance now existing as enums, enabling modular, extensible validation.

Pull Requests

We’d like to thank Aviad Pineles for their PR to improve CSS style sheet logic for pdfHTML. While we eventually went with a different implementation of this fix, we’re very grateful for the inspiration!

Bug Fixes and Miscellaneous

In line with our efforts on the PDF/UA-2 checks and the upgraded API for converting HTML to PDF/UA, we also have some enhancements and fixes for general PDF 2.0 conformance. One of the standout updates is a dedicated checker that evaluates tag structure by examining the parent-child tag relationships as outlined in the PDF 2.0 specification. We’ve also addressed a number of issues related to PDF 2.0 tag conversion and structure repair operations, making sure everything operates seamlessly.

We would also like to highlight an additional change: in response to a bug report on StackOverflow, we identified and resolved a line wrap issue affecting non-wrapping italic and bold simulated text within table columns. This problem could lead to incorrect page breaks when the content width exceeded the column limits. To fix it, we’ve adjusted the table renderer logic to handle cases where text formatted in such ways exceeds the layout box width.

Other Stuff

Those of you who were intrigued by the reference to Python at the beginning will be interested in a new article in our Technical Tales section of the Knowledge Base. Vlad Lipskiy from our Research Team has been very busy over the past few weeks exploring how Python.NET can enable direct usage of iText from Python. In addition to porting a wealth of code samples, he’s also written a superb article which takes a deep-dive into how it all works. Make sure to check it out!

Another great article is by Guust Ysebie from the iText SDK development team. If you caught the iText Core 9.1.0 release, you might remember how we managed to massively speed up table rendering, particularly in the case of tagged tables. If you wondered how this was possible, Guust has written up the whole story from beginning to end. It’s a very entertaining and enlightening read, so if optimization is your bag you’ll find a lot to enjoy.

NOTE: 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:

As always, you can see the Changelog below to see the full rundown on what’s new in Core, and details of other improvements and bug fixes for this release.

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 for .NET MAUI AOT compilation
  • Automated checks for PDF/UA-2 Validation
  • Introduce PDF 2.0 tag structure checker

Improvements

  • toLowerCase/toUpperCase locale independent usage
  • Use System.Text.Json instead of Newtonsoft.Json for netstandard 2.0
  • Added copyright attribution clarification for jsoup-related files

Bug fixes

  • Cell with non breakable content and not enough horizontal space leads to page break and data loss
  • Font selection breaks tag structure
  • BitsPerComponent: 1 and Indexed DeviceRgb failes with "The color depth 1 is not supported error."
  • Wrapping ListItem content in a Div with list symbol inside causes wrongly aligned content
  • KeepWithNext property causing formatting issue
  • PDF 2.0 does not allow DIV, P tags to be children of the P tag
  • PDF 2.0 does not allow P, Hn tags to be children of the Form tag
  • PDF 2.0 documents should not contain Document tag if it does not contain any content
  • Improve AESCipherCBCnoPad documentation
  • sxHeight is not set in OS/2 table metrics when processing TTF fonts
  • Standard security handler issue with long value for user access permissions
  • Wrong relative width calculations for hr tag
  • Distinguished Name comparison should be done using the equivalent method instead of the equals method
  • Incorrect producer line for LTA signatures in AGPL mode
  • PdfDocument Constructor causes endless loop
  • setAlternativeDescription doesn't set Contents entry for PdfSigner
  • PdfUAConformanceException when SignatureFieldAppearance contains Image

Contributors

We’d like to shout out the following contributors for this anniversary release:

Assets 9
Loading