NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
NuGet · #921 most downloaded on NuGet
iText represents the next level of SDKs for developers that want to take advantage of the benefits PDF can bring. Equipped with a better document engine, high- and low-level programming capabilities and the ability to create, edit and enhance PDF documents, iText can be a boon to nearly every workflow. iText allows you to build custom PDF scenarios for web, mobile, desktop or cloud apps in .NET.
Last release 8 days ago
30 Sep 2026
Ships on a steady schedule
a new release about every 3 months
Nearly every release is documented
notes for 50 of 51 stable releases
Nothing withdrawn
no release was ever pulled
10 years old
53 releases · first in 2016
We are pleased to announce the release of iText Core 9.8.0. This release introduces support for vertical text layout and CJK writing modes, radial gra
We are pleased to announce the release of iText Core 9.8.0. This release introduces support for vertical text layout and CJK writing modes, radial gradients and SVG mask support, and advanced SVG stroke properties. In addition, we’ve introduced a higher-level transformation API with more user-friendly affine transform capabilities in the Layout module, enhanced footnote navigation, critical security updates across key cryptographic and utility dependencies, and substantial performance and standards-conformance improvements.
iText Core 9.8.0 introduces initial support for vertical writing modes in the Layout module, primarily aimed at CJK (Chinese, Japanese, and Korean) layouts. Whilst the implementation is not yet complete, the API has been finalized and supports line breaking, baseline adjustments, right-to-left vertical progression, accessibility tagging, and improved sizing behavior in tables, flex containers, inline blocks, and text renderers.
The current implementation also covers word and character spacing, text alignment, overflow handling, text decorations, and text-rise behavior, with related pdfHTML alignment for CSS vertical writing modes.
The Layout module now includes more user-friendly affine transformation capabilities, with simplified API options for Property.TRANSFORM. The release also resolves layout issues affecting rotated table cell sizing, content offsets, rotated page coordinates, and relative image positioning with borders.
This release expands SVG and graphics fidelity with radial gradient support across SVG, Kernel, and Layout, SVG support via PDF soft masks, advanced stroke properties such as stroke-linecap, stroke-linejoin, and stroke-miterlimit, URL-based stroke references with fallbacks, and fixes for nested clip paths with translations.
Related to the SVG improvements, we’ve been working on providing Markdown-to-PDF conversion via GitHub Actions. It isn’t part of this release, but we’ll share more very soon.
iText Core 9.8.0 includes important security and stability updates across cryptographic, JSON, HTTP, and logging dependencies, including IV generation fixes, Bouncy Castle FIPS, Bouncy Castle standard libraries, Jackson Databind, Apache HttpClient, and Logback. It also improves PDF/A and PDF/UA validation, text extraction performance, circular reference protection, digital signature revision validation, custom font link handling, font resource licensing clarity, and runtime compatibility for .NET 10 environments.
We’d like to thank Netliomax25 for their fix to improve CSS ~= attribute selector matching in pdfHTML and styled-xml-parser by properly escaping selector values before pattern matching.
Beyond the headline features, iText Core 9.8.0 includes a broad set of fixes and maintenance updates focused on performance, standards conformance, document stability, packaging quality, and developer experience.
Performance and resource handling: Restored Standard 14 font caching in text extraction to address a performance regression, added circular form XObject protection in canvas processing and cleanup workflows, and optimized conditional logging to avoid unnecessary string formatting when log levels are disabled.
PDF/A, PDF/UA, and validation improvements: Improved validation for PDF/A documents with multi-stream page contents and refined glyph validation for substituted glyphs without Unicode mappings.
Digital signing and document integrity: Corrected revision counting in digital signature validation to avoid over-counting document processing events and improve validation reliability.
Layout and rendering fixes: Fixed issues involving custom font links, relative image positioning with borders, rotated table cell sizing, footnote numbering with footer and page-break handling, and margin handling during relayout.
Packaging, runtime compatibility, and documentation: Improved .NET 10 compatibility, centralized .NET build configuration, fixed licensekey and iText Core tests for .NET 10, and expanded public API documentation for the io module.
Compliance and dependency hygiene: Replaced legacy bundled font resources with clearly licensed equivalents and updated related notice information.
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.
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
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. Read this article to learn more about ZUGFeRD/Factur-X, and using these code samples to create EN 16931-compatible e-invoices.
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.
DEVSIX-9388, DEVSIX-10118, DEVSIX-10136, DEVSIX-10137, DEVSIX-10155, DEVSIX-10161, DEVSIX-10162, DEVSIX-10163, DEVSIX-10166, DEVSIX-10167, DEVSIX-10168, DEVSIX-10175, DEVSIX-10183, DEVSIX-10190 – Initial vertical text layout & CJK writing modes
DEVSIX-9377, DEVSIX-10102, DEVSIX-10150 – Higher-level affine transformations in the Layout module
DEVSIX-4396, DEVSIX-10037 – Radial gradient support across SVG, Kernel, and Layout
DEVSIX-2378 – Converting SVG elements into PDF soft masks
DEVSIX-10025, DEVSIX-10031 – Bi-directional clickable links between footnote anchors and bodies, with custom styling support for footnote anchors
DEVSIX-2623, DEVSIX-10156, DEVSIX-10180 – Vertical text formatting, alignment, overflow, text-rise, and CJK font metrics
DEVSIX-2258, DEVSIX-4857, DEVSIX-10171 – SVG stroke properties, URL stroke references, and nested clip paths
DEVSIX-5334, DEVSIX-8934, DEVSIX-5029 – Rotated layout handling for table cells, offsets, and page coordinates
DEVSIX-10034, DEVSIX-10101 – Margin handling during document relayout
DEVSIX-10100 – Font resolution for footnote anchors
DEVSIX-10192, DEVSIX-10142, DEVSIX-10174, DEVSIX-10165, DEVSIX-10172, DEVSIX-10170, DEVSIX-10203, DEVSIX-10169, DEVSIX-9733, DEVSIX-6172 – Security updates for IV generation, Bouncy Castle, Jackson Databind, HttpClient, and Logback
DEVSIX-10113, DEVSIX-10092, DEVSIX-10026, DEVSIX-10179 – .NET 10 / GraalVM compatibility, and io API documentation
DEVSIX-9682, DEVSIX-9683 – Font compliance updates and notice file cleanup
DEVSIX-5525 – Conditional logging optimization to avoid unnecessary string formatting when log levels are disabled
DEVSIX-10112 – Restoring Standard 14 font caching in text extraction
DEVSIX-3608 – Stack overflow protection for circular form XObjects
DEVSIX-10089 – Multi-stream PDF/A validation syntax boundary fix
DEVSIX-10160 – Substituted glyph validation via direct glyph-code lookup
DEVSIX-10177 – Signature revision count accounting
DEVSIX-10130 – Custom FontProvider handling on Link elements
DEVSIX-10019 – CSS ~= selector value escaping
DEVSIX-10094 – Footnote numbering with footer and page-break handling
DEVSIX-1022 – Relative image positioning with borders
We’d like to shout out the following contributors for this release:
One column per quarter.
Our third iText Core release of 2026 brings some significant new capabilities. We've added support for the WebP image format, introduced dynamic page
Our third iText Core release of 2026 brings some significant new capabilities. We've added support for the WebP image format, introduced dynamic page margins and footnotes to the layout module, and strengthened decompression bomb protection. We've also improved append mode reliability and updated several security-related dependencies.
iText now natively supports the WebP image format, developed by Google to provide superior lossless and lossy compression for web images. This new capability allows you to integrate high-quality, highly compressed modern web images directly into your PDF workflows, significantly reducing file sizes without sacrificing visual fidelity.
Our implementation uses SkiaSharp for WebP decoding on .NET and is delivered as a separate, optional module: webp-image-support. When the module is referenced in your .NET project, iText Core automatically detects and processes WebP images without requiring any additional configuration.
We have completely overhauled the way iText handles complex document layouts. This not only allows developers to adjust page margins on the fly, but also includes footnote support with automatic numbering, customizable footnote containers, and intelligent layout logic that ensures footnote anchors and text remain perfectly positioned.
To achieve this, we have introduced a powerful new framework for managing complex document layouts. This overhaul allows developers to adjust page margins on the fly using the new SectionBreak element.
Additionally, we’ve launched comprehensive footnote support, enabling automatic numbering, customizable footnote containers, and intelligent layout logic that ensures footnote anchors and text remain perfectly positioned.
We’ve resolved critical issues related to Append Mode, ensuring that incremental updates to PDF documents are more reliable. This includes better tracking of modified objects and fixing stream inconsistencies, allowing for a more robust document history and preservation of digital signatures.
Page rotation handling for signature layers is also improved, and we fixed some edge-case crashes during form flattening.
To ensure uninterrupted support for digital signature validation, we have released a new version of our EU Trusted Lists resources. This update incorporates the recently updated European Journal sources, maintaining compliance with the latest eIDAS standards.
iText’s protection against "decompression bombs" inside PDF streams has been enhanced, particularly for single /FlateDecode streams and image-based decompression bombs. The change applies a 100× growth factor limit to all streams by default. Note that the existing API to override protection remains in place, in cases where edge cases may trigger false positives. However, this should be extremely unlikely for real-world uses cases.
Additionally, we have implemented a high-level safety mechanism to detect and terminate infinite layout loops.
For this release we've incorporated two pull requests. The first is from iText alumni Dmitry Radchuk to add support for the :is() and :where() selectors for the styled-xml-parser module utilized by the pdfHTML add-on. Therefore, full details can be found in the pdfHTML 6.3.3 release notes.
The other pull request comes from Netliomax25 who proposed a way to increase security in iText’s PDF/UA accessibility checks, specifically for rich text inside annotations. The fix swaps in a hardened XML parser to block potential XML External Entity injection attacks.
WA customer-reported NullPointerException during form field flattening was fixed. The issue occurred when a signature field contained an invalid appearance entry (a non-stream object declared as a Form XObject). iText now logs a warning and skips the invalid appearance instead of crashing.
A PDF/A-2 conformance validation bug was fixed where PdfA2Checker.checkSeparationCS incorrectly threw an exception when two Separation color spaces with different names were used. The checker was not properly comparing the color space names, treating all Separation spaces as having the same name. This fix also applies to PDF/A-3 and PDF/A-4 conformance checking.
We added a high-level mechanism to prevent infinite loops in the layout module. In rare edge cases involving complex combinations of keep-together, forced placement, and nested containers, layout could enter an infinite loop. The engine now detects such situations and forces placement after a configurable number of iterations.
An informational warning is now logged when text requires the pdfCalligraph add-on for correct rendering but pdfCalligraph is not available. This helps developers identify rendering issues with complex scripts early in development.
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.
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
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. Read this article to learn more about ZUGFeRD/Factur-X, and using these code samples to create EN 16931-compatible e-invoices.
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.
We’d like to shout out the following contributors for this release:
…causing security tools to flag as vulnerable to CVE-2024-21907 due to outdated dependencies. This has been resolved by updating the Microsoft.Extensio…
Our second iText Core release of 2026 will please those with a focus on creating accessible and reusable content in PDF. We’ve introduced the ability for iText to perform automatic color contrast checks during creation of PDF/UA documents, which will aid when ensuring generated documents meet many countries' accessibility regulations.
We’ve also added high-level functionality to make creation of Well Tagged PDF documents easier, by letting iText’s comprehensive conformance checking architecture handle all the tricky stuff behind the scenes. You can also target the reuse and accessibility conformance levels defined in the WTPDF specification, depending on your requirements. The accessibility level directly aligns with PDF/UA-2, while reuse is optimized for content extraction, reflow, and machine-driven transformation.
In addition, we’ve extended trusted list validation to include non‑EU countries, along with general improvements to digital signature validation and certificate retrieval.
For documents to comply with the PDF/UA specifications, you must ensure that foreground and background colors meet the necessary WCAG standards for accessibility. If there is not enough contrast then not only will documents fail in accessibility checkers, text and graphical content will be difficult to read.
Color contrast checking is something that still requires human intervention in most cases, however, iText Core can now warn you if such issues are detected during document creation. It should be noted that this is not a comprehensive check and cannot substitute for an actual “human in the loop”. However, it will help to identify and avoid obvious issues at an early stage.
This functionality is similar to that provided by the WebAIM Contrast Checker, where you can select different values for the foreground and background colors. For WCAG 2.1 level AA which is commonly specified in accessibility regulations, normal text must have a contrast ratio of at least 4.5:1, and 3:1 for large text, graphics, and user interface components (such as form input borders).
We have also improved iText’s layer handling to better accommodate these tests. Previously, reopening a document and accessing layers via PdfPage.getLayers() always returned layers in the “on” state regardless of their persisted visibility. Now, layer properties are correctly persisted after saving and reopening.
The PDF Association’s Well-Tagged PDF (WTPDF) standard specifies requirements for creating PDF 2.0 documents geared towards reuse and accessibility. While both use cases have a large overlap in requirements, some are critical for reuse while others are only required for accessibility. Therefore the standard has conformance levels that clearly identify the requirements for each.
The reuse level is intended for PDF content to be more easily repurposed, extracted, or reflowed, including use cases such as PDF to HTML conversion and enabling responsive layouts on mobile devices. The accessibility level uses the same structural tagging model, but focuses more on ensuring people using assistive technologies can navigate and understand the document.
WTPDF document creation with iText Core was introduced along with the support for PDF/A-4 and PDF/UA-2, which are both based on the PDF 2.0 specification. However, we’ve since added a comprehensive validation architecture with specialized document classes and validation checkers to enforce compliance when targeting specific standards.
To bring WTPDF into line there is now a dedicated WellTaggedPdfDocument subclass of PdfDocument, to join the existing PdfADocument and PdfUADocument classes. In addition, the PdfConformance class now includes the accessibility and reuse conformance levels.
All these changes mean creating WTPDF documents with iText is just as easy as PDF/A and PDF/UA, with no need to worry about remembering which requirements apply to the conformance level you’re targeting. You can now simply use WellTaggedPdfDocument to create a WTPDF document just like you would use PdfUADocument to create PDF/UA, and let iText do the hard work for you.
In iText Core 9.3.0 we introduced the List of Trusted Lists (LOTL) system, which lets iText fetch, validate, and cache European lists for eIDAS compliance. To better accommodate other countries which also issue and maintain trusted lists of their own, we’ve extended the feature to include a broad non‑EU processing implementation.
This was achieved by adding a convenient “single file trust list” alternative implementation path, useful for countries where you have a single XML trust list rather than an EU-style LOTL + pointers ecosystem. The existing LOTL services have been refactored to support this, and the existing Ukraine and Moldova trusted lists samples have been updated to use this new implementation.
You can refer to the Java and .NET sample repositories to find the LOTL validation examples updated for this release.
For digital signature validation we’ve introduced a single, configurable mechanism to control all online data retrieval (such as CRL, OCSP, issuing certificates, and LOTL), making it easier to enforce network policies and increase reliability in restricted environments.
Certificate chain building and validation have been updated to better handle complex PKI setups. Chain construction now collects all reachable certificates, including multiple CA candidates and cross-signed certificates, without enforcing constraints during the building phase.
Validation then applies RFC 5280–compliant checks over the resulting paths, with a particular focus on correctly enforcing inherited name constraints across the entire certificate chain. This separation of chain discovery and validation improves robustness and correctness when working with real‑world certificate hierarchies.
For this release we’d like to thank schallb for their contribution to improve LocationTextExtractionStrategy (Java/.NET) by adding support for custom element and newline separators.
As the author describes, they needed a way to better distinguish between spaces and newlines that are part of the extracted text, and the separators inserted by iText when it decides a word boundary or new line between chunks exists. Thanks to this change, the separators inserted in the formatted extracted text can be overridden.
We also resolved a few customer and internally-reported issues. The MemoryLimitsAwareHandler (Java/.NET) which protects applications from using too much memory when reading or processing PDF content was modified to have different behavior when creating xref tables rather than updating them. The documentation has been updated to reflect these changes.
We fixed an issue where certain Type3 fonts are processed incorrectly, causing multiple glyphs that share the same Unicode mapping to render with incorrect or duplicated content streams. This resulted in missing or wrong glyph appearances when using or extracting the font.
A regression was reported where signing a PDF removed the /DA (default appearance) entry from signature fields, triggering change warnings in Acrobat and affecting re-signing. The fix ensures the DA entry remains untouched during signing to preserve appearance and avoid Acrobat warnings.
An issue was fixed when copying pages from certain PDF/A-converted documents whose outline/action dictionaries were altered (using /Dest instead of /A), leading to a PdfException error reporting an object belonged to a different PDF. Another PDF/A-related fix prevents null pointer exceptions during PDF/A compliance checks by ensuring the content-stream validation parser is given the correct resource dictionary.
Error handling was improved in a few other cases too. For example, iText now throws a clear, specific error when a PDF annotation is missing its required subType property, instead of failing with a generic null pointer exception. A generic null reference exception when merging certain PDFs was replaced by clearer error reporting when input PDFs have syntax issues, making it easier to identify where the problem lies.
For .NET, we resolved an issue where older versions of the Newtonsoft.Json transitive dependency could be pulled for .NET Framework 4.6.1, causing security tools to flag as vulnerable to CVE-2024-21907 due to outdated dependencies. This has been resolved by updating the Microsoft.Extensions.DependencyModel to 10.0.2. This did not apply to .NET Standard 2.0, where since iText Core 9.2.0 we switched to use System.Text.Json instead.
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.
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
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. Read this article to learn more about ZUGFeRD/Factur-X, and using these code samples to create EN 16931-compatible e-invoices.
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.
We’d like to shout out the following contributors for this release:
In this first iText Core release of 2026 we’re focusing on upcoming additions to the PDF specification; specifically adding support for Brotli-compres
In this first iText Core release of 2026 we’re focusing on upcoming additions to the PDF specification; specifically adding support for Brotli-compressed PDF streams, and post-quantum-safe algorithms for digital signing.
The validation of PAdES signature profiles has been improved to detect Document Security Store changes between revisions.
In addition, there are various improvements and fixes across the core modules. See below for more details.
The Flate/Deflate compression method was first introduced in version 1.2 of the PDF specification back in 1996. Based on zlib, it has served well though is rather long in the tooth these days. With that in mind, the PDF Association plans to add support for the modern Brotli compression standard to the PDF specification in the near future. As befits our position in the industry, we're introducing Brotli support to iText now rather than later.
In this release we’ve added proof‑of‑concept support for reading and writing PDFs that use Brotli compression, including a new filter handler and corresponding high‑level API hooks.
For now at least, you should consider this feature experimental, since current support for Brotli-compressed PDFs in other software is scarce. Even after it becomes part of the official specification it will take some time for the majority of PDF viewers and browsers to support such documents. As always with new standards and technology, however, it's important for iText along with other major PDF vendors to adopt and popularize them as soon as possible.
For those brave souls who wish to proceed, the new brotli-compressor module is only available from our artifactory, for now. See the README for more details on its usage and configuration.
Once again, this is one for the future; albeit a rather more uncertain one. Quantum computers are beginning to step outside of the purely theoretical world, and with them comes the dangers of Q-Day. That is, the day when a quantum computer could conceivably instantly render existing means of encryption obsolete.
Fortunately, some extremely clever boffins have been aware of the dangers for some time, and a variety of encryption algorithms has been developed to counter quantum-based attacks. Thanks to the venerable Bouncy Castle cryptographic modules used by iText, we have implemented POC support for the Post-Quantum algorithms supported by Bouncy Castle.
Again, official support in the PDF specification will be coming soon and so it's time for us to implement support in iText. However, it should be noted that these are not yet supported in FIPS mode, as the official PQC-safe algorithms for FIPS are still to be defined. Once PQC-safe FIPS mode is possible, you can be sure iText will be at the forefront of PDF implementations.
We've made further headway into making digital signatures easier with preset PAdES signature profiles. The PAdES profile validation is improved and can detect when the Document Security Store (DSS) changes between revisions. It will emit a TimestampsAfterDSSEvent when appropriate, improving timestamp validation accuracy.
Also in this release you'll find new samples for the Ukraine and Moldova trusted lists which are available from the European Commission's eIDAS Dashboard site.
For this release we want to thank dajoropo for their contribution to improve error handling when an attempt to create a PDF from a TIFF image fails. Now, iText Core will include the original exception to assist in diagnosing why the error occurred.
We have introduced a common, cross‑platform JSON AST and converters to serialize/deserialize between Java/C# objects and a unified JSON representation, improving maintainability and GraalVM/AOT support.
Support for East Asian (Japanese) line‑breaking rules in the layout module was added to avoid orphan punctuation at the beginning of lines, improving typography for Japanese text.
We also investigated and resolved an issue with form filling and flattening introduced after version 9.0.0, after a customer reported a regression in performance.
A bug in calculating the maximum number of XRef elements was fixed, avoiding potential overflow issues in large documents.
We fixed an issue preventing OCG layers from being added, modified, or removed in append mode was fixed, including when no prior OCG layers existed.
We also fixed the handling of unencrypted metadata in encrypted documents by aligning decryption logic with encryption dictionary flags (AES‑256 vs AES‑GCM behavior), and clarified how metadata is treated on creation.
A bug when validating a PDF signature was resolved, where iText did not use OCSP/CRL responses that were added to the document’s DSS in a non-timestamped revision.
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.
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
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. Read this article to learn more about ZUGFeRD/Factur-X, and using these code samples to create EN 16931-compatible e-invoices.
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.
We’d like to shout out the following contributors for this release:
For our fourth and final iText Core release of 2025 we’re introducing advanced page resizing functionality for more effective merging and manipulation
For our fourth and final iText Core release of 2025 we’re introducing advanced page resizing functionality for more effective merging and manipulation of PDF documents with varying page sizes.
We’ve also been working on extending the new EU eIDAS Trusted Lists feature to support validation against specific signature profiles.
In addition, we’ve enhanced our flex layout support within the layout module for use with the pdfHTML add-on.
This release introduces advanced page resizing functionality, allowing users to merge and manipulate PDF documents with varying page sizes more effectively. This was based on a customer request who was using similar functionality in iText 5. However, the way iText 5 did this was relatively unsophisticated, and ran into problems with tagged documents and different content types.
This new implementation addresses scenarios such as scaling content between different page formats (A0, A1, US Letter, etc.), maintaining aspect ratios, and handling annotations, patterns, gradients, and form fields during resizing. The result is a more flexible and reliable toolkit for document assembly and transformation, ensuring that content integrity and layout are preserved across diverse PDF workflows.
This focuses on enhancing digital signature capabilities in iText Core by introducing support for signature profiles. This feature enables an easier way to ensure that digital signing and validation processes meet the regulatory and compliance requirements for specific regions. As a demonstration, we’ve updated the LotlSimpleSignatureValidation sample (Java/.NET) on GitHub to show off the new QualifiedValidator class. This determines if a given certificate/signature meets the regulatory standards to be “qualified”, which is vital for high-trust electronic transactions.
We’ve also made a change to LOTL validation reports to eliminate multiple successful validation messages during the process, along with some general improvements to LOTL caching and validation.
This release significantly improves the flex layout support in the core Layout module. Since this primarily affects pdfHTML, you’ll find more details in the release notes for pdfHTML 6.3.0.
We’d like to thank IBaltaga for their suggested NotSupportedException if AreaBreak is inside a flex container fix for .NET. After investigating in more detail we decided to implement the fix in a different way, however, an exception will no longer be thrown for AreaBreaks inside flex containers.
PDF image and color depth handling has been enhanced when extracting images There are also accessibility and structure improvements in generated/tagged documents, and error messaging and recovery for malformed or edge-case PDFs is improved.
For .NET, we’ve implemented a wrapper for Asn1OutputStream which became available in version 1.0.2 of BC FIPS .NET. This improves cryptographic compatibility for FIPS workflows.
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.
We’d like to shout out the following contributors for this release:
For this Q3 release of iText Core we’ve further enhanced iText’s digital signature validation by adding support for the official EU eIDAS Trusted List
For this Q3 release of iText Core we’ve further enhanced iText’s digital signature validation by adding support for the official EU eIDAS Trusted Lists. Not only that, there’s also improvements to thread safeness and further work on the .NET MAUI support we introduced in version 9.2.0.
Furthering our efforts to make developers' lives easier when dealing with PDF digital signatures, we’re pleased to announce that iText now supports retrieval, validation, and usage of the EU’s List of Trusted Lists (LOTL). This greatly simplifies the process of establishing a chain of trust for electronic signatures, and helps ensure that signatures validated with iText meet stringent European standards for trust and authenticity..
For those unaware, the LOTL is a central, signed XML file containing links to trusted lists from EU and EEA Member States. These Member State lists identify both trust service providers and the trust services they offer; e.g. digital signatures and seals. The LOTL is an official resource which aids achieving compliance with EU eIDAS regulations. Previously, you would need to manually provide the trusted certificates to use for validation with iText; which is still possible, but is less convenient. Now, iText will retrieve, parse, and validate the LOTL to provide the root trusted certificates for you.
For security reasons, rather than expect iText to repeatedly retrieve the trusted certificates to validate the LOTL from the Internet, we instead provide a specialized repository which has the required certificates pre-downloaded. This can be found on GitHub, or alternatively on Maven and NuGet.
You can find full details on this implementation and its usage linked in the release notes on the iText Knowledge Base.
Internal updates have improved thread safety across key components, making iText Core more robust in multithreaded environments. This is especially beneficial for developers building scalable, concurrent applications.
.NET performance improvements include replacing for loops with foreach loops. The iText.Kernel.XMP.Impl.ParseRdf class is heavily used in XML-based metadata parsing, and the change significantly speeds up processing of large XMP collections.
Building on the support for Native AOT compilation in the previous release, iText Core now offers better compatibility with .NET MAUI, supporting cross-platform mobile and desktop development and integration into modern .NET applications.
We’d like to thank SangeethaDivya for their contribution to remove duplicate constants on .NET, which we used as a basis for a Java reimplementation and ported it to .NET. Thanks also to craffael who fixed a typo in the PDFA-1 checking code which led to documents with no device-dependent color spaces failing the checks.
A bug in PDF 2.0 structure destinations has been fixed, improving how tagged content is linked and navigated when converting from HTML. This is now more in line with the PDF 2.0 and PDF/UA-2 specifications and is particularly useful for accessibility and structured document workflows.
We’ve also fixed an issue related to color depth support in PDF image data streams, which would result in an com.itextpdf.io.exceptions.IOException: The color depth 1 is not supported. error.
We’ve also resolved a StackOverflowException resulting from invalid PDFs with cyclic references in the trailer dictionary, improving robustness and error handling.
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.
We’d like to shout out the following contributors for this anniversary release:
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, bec
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???
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 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.
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!
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.
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.
We’d like to shout out the following contributors for this anniversary release:
To celebrate both iText’s 25th anniversary and Valentine’s Day, we bring you iText Core version 9.1. There’s a lot of to love about this release, with
To celebrate both iText’s 25th anniversary and Valentine’s Day, we bring you iText Core version 9.1. There’s a lot of to love about this release, with a huge performance increase in table creation, massively extended SVG support, and further Digital Signing goodies.
Many additions and enhancements have been made to our in-house implementation since it was introduced, with coverage of the specification steadily increasing to meet customer needs. This release sees our biggest leap yet with over 40 tickets being closed – full marks to our incredible dev team!
Newly added are support for text clipping paths, 'marker-mid' properties, text decoration, and passing markers from elements to children. We’ve improved general font handling, while some other improvements to draw attention to are in the support for relative size attributes, text positioning, 'direction' properties, stroke opacity, and dash patterns.
There's also improved support for CSS-specific SVG, which you can find more details on in the pdfHTML release notes. However, we'll call out the improved support for different CSS origins in SVG and referencing external resources with the @importurl() rule.
To top it off we’ve significantly improved the SVG module’s usage of the advanced typography features enabled by the pdfCalligraph add-on. See the example PDF on our Knowledge Base for a demonstration!
With iText Core 9.1 the table rendering code has been highly-optimized, particularly when it comes to tagged tables. This is especially noticable for tables with many rows, or when tagging tables. See more details
We’re continually working on iText’s digital signing and validation capabilities to provide a unique breadth of support in the market. MAC integrity protection support is extended to support two-step signing. There’s also new code examples for signing with the Cloud Signing Consortium (CSC) API, which we recently wrote about in Part V of our Digital Signing with iText series. You can find these in the GitHub samples repositories linked below.
Alongside that, we’ve made some general improvements (if you know, you know) to signing and validation. In particular, the workaround for certificates where the pathLength parameter is set to 0 for the basicConstraints extension is no longer required.
Our PDF/UA-2 implementation is improved, specifically, when using the Annot tag for content elements in PDF 2.0 documents.Don’t tell anyone, but our team is preparing further PDF/UA-2 goodies for our next release.
For this release, we’d like to thank Stefan Bechtold for submitting a PR adding support for styling tables with nth-last pseudo class selectors. Thanks also to Artyom Skrobov for squashing a bug when decoding an empty PdfString, and finally Zuzu-Typ for fixes to the kernel PDF encryption constants documentation.
There’s an update for merge handling when remote and embedded go-to actions are present, and we resolved a customer issue related to decoding Xref streams with missing bytes.
Many bugs have been resolved for SVG rendering and CSS layout. In addition, general bugfixes have been made to font and text handling, form fields, signing and validation, and more.
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
.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.
We’d like to shout out the following contributors for this anniversary release:
The iText Knowledge Base has extensive documentation on the breaking changes to ease the migration of existing projects from earlier versions.
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.
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.
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.
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.
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.
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.
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
.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.
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…
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.
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!
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.
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).”
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.
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.
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.
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.
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.
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
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.
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!
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.
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).
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.
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.
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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Nothing published for this version
-
Nothing published for this version
-
-
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →